! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
unnecessary redraws on xfwm4 window resizing
Status:
RESOLVED: MOVED

Comments

Description rtc 2008-08-14 13:25:19 CEST
I noticed some oddity when resizing windows with xfwm4 by using the upper left corner to make the window larger.  If I do that, parts of windows that should be completely covered by the window to be resized before and after the resize are visible for a short amount of time. It looks as if xfwm first changes the window's position, keeping its old size, and only after that it is enlarged.

  x <- pull upper left  +------+            +------###
   \   corner           |      |    only    |      ###
    +------+         => |      |##  now     |      ###
    |      |            +------+##   =>     ##########
    |      | background   ########          ########## <- redrawn
    +------+   redrawn -> ########          ##########
            (unnecessarily)

The right thing would obviously be to skip the step in the middle. This is quite annoying because of the flickering the slowliness caused by the unnecessary redraws.

I configured xfwm4 to use opaque resizing, not wireframe resizing.  I observed this problem on both Fedora 9 and Ubuntu 8, so I think it's a problem of xfwm4 itself.  Metacity and fvwm don't have this problem.
Comment 1 Olivier Fourdan editbugs 2008-08-14 15:04:26 CEST
Unfortunately this is not how it's done in the code, it's using a single XConfigureWindow().

I suspect this has to do with the way the xserver handles the configure, because damages are generated in the area during the resize (thus confusing even more the compositor, do you have the compositor enabled?)
Comment 2 rtc 2008-08-14 15:10:39 CEST
I don't have the compositor enabled. Can you reproduce the problem?
Comment 3 Olivier Fourdan editbugs 2008-08-15 20:58:40 CEST
Ok, I've committed a change in the way both the decorations/frame/client window are updated to avoid this problem.

Additionaly a hook has been added to the compositor to update the compositor during resize as relying on configure notify introduces a lag and ugly effects.

Current SVN trunk works as expecteed now (as far I can tell/see).
Comment 4 rtc 2008-08-21 00:43:27 CEST
Great, thanks!  I would love to confirm that the problem has indeed been solved, but if I try to compile the svn version on Fedora 9, it complains about xfconf being missing.  I changed the status to FIXED anyway, as what you write sounds very promising.  As soon as I get the new version working on some future Fedora, I will then report remaining problems, if any (but I don't expect any).
Comment 5 rtc 2012-05-31 01:40:58 CEST
This bug has not been fixed completely. While the instance I described (increasing the window size) works fine now, I still get unnecesary redraws when *shrinking* the window:

                              background redrawn
                           v- (rightly)
  +--------+            **********
  |\       |            **********  only
  | x      |      =>    **      ##  now       ########    window
  | ^-pull |            **      ##   =>       ########    contents
  | to here| background **########            ######## <- redrawn
  +--------+  redrawn   **########            ########    
           (unnecessarily)-^
Comment 6 rtc 2012-05-31 01:55:15 CEST
btw, now using xfce 4.8...

One further note: I don't know if xfwm is responsible for this or the application, but increasing the window size now does this (tested with mousepad, gedit, firefox, ...):

                           .-----copied
                           | (unnecessarily by xfwm?)
                           v  
  x <- pull upper left  +------+            ##########
   \   corner           |      |    only    ##########
    +------+         => |      |-+  now     ##########
    |      |            +------+ |   =>     ##########
    |      |              |      |          ########## <- redrawn
    +------+              +------+          ##########
            
obiously, the second step can simply be skipped.
Comment 7 Olivier Fourdan editbugs 2012-05-31 09:03:20 CEST
Unlikely I will fix this 4 years later.
Comment 8 rtc 2012-05-31 16:09:39 CEST
Don't misunderstand me to ask for a fix in older versions, but it would be great if it could be fix it for future versions...
Comment 9 Git Bot editbugs 2020-05-29 11:39:47 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/15.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #4283

Reported by:
rtc
Reported on: 2008-08-14
Last modified on: 2020-05-29

People

Assignee:
Olivier Fourdan
CC List:
0 users

Version

Attachments

Additional information