When Xfwm's compositor is enabled, it unconditionally marks the entire framebuffer as damaged, on every frame. This can cause performance problems under certain conditions, such as when used with intel-virtual-output: https://bugs.freedesktop.org/show_bug.cgi?id=96820#c3 Furthermore, it's definitely not power-efficient, which is a factor in laptops and mobile devices.
Which version of xfwm4? which backend, present, glx, xrender?
Thanks for your quick response! xfwm4-4.12.3, how do I find out which backend is in use? Or is that a new feature in git?
(In reply to haarp from comment #2) > xfwm4-4.12.3, how do I find out which backend is in use? Or is that a new > feature in git? It's a new feature in git, if you use the released version, you're using the xrender backend which does not mark the entire framebuffer as damaged but clips the regions as necessary... So I don't understand the comment/bug report.
I just had a look at Xfwm4 git. According to the debug log, it's using GLX. Yet the effect is the same, which is choppy performance when the compositor is enabled in connection with intel-virtual-output. I also tested XFWM4_USE_PRESENT with the same result. So none of the backends seem to make a difference. The issue appears irregardless of whether vsync is enabled or not. I assumed that Chris Wilson was correct when he said that the entire framebuffer is getting damaged (seeing as he's Intel's driver dev) but maybe that's incorrect. How do I verify this? The only noteworthy reference to damage are lines like these: XError: BadDamage (invalid Damage parameter) ==> XID 0x5200833, Request 142, Error 149 <==
(In reply to haarp from comment #4) > I just had a look at Xfwm4 git. > > According to the debug log, it's using GLX. Yet the effect is the same, > which is choppy performance when the compositor is enabled in connection > with intel-virtual-output. Please try with the released version, not git master. > I also tested XFWM4_USE_PRESENT with the same result. > > So none of the backends seem to make a difference. The issue appears > irregardless of whether vsync is enabled or not. vsync in xfwm4 doesn't make much sense anyway, even less in master. > I assumed that Chris Wilson was correct when he said that the entire > framebuffer is getting damaged (seeing as he's Intel's driver dev) but maybe > that's incorrect. I am not saying Chris is incorrect (if the logs shows the entire framebuffer is damaged, then it's true, I have no reason to doubt that), but if using the 4.12.x (ie again, not master), the repaint uses clipping so only the relevant part of the screen should be repainted. If that's not the case, then maybe there is a bug in clipping, I don't know. Now, if this happens with a fullscreen video playback window, chances are the actual region to repaint is as large as the screen... > How do I verify this? The only noteworthy reference to > damage are lines like these: > > XError: BadDamage (invalid Damage parameter) > ==> XID 0x5200833, Request 142, Error 149 <== That's irrelevant.
-- 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/228. 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