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.
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?)
I don't have the compositor enabled. Can you reproduce the problem?
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).
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).
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)-^
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.
Unlikely I will fix this 4 years later.
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...
-- 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