Bug 311592 - ScreenEdge::raisePanelProxies() is slow due to sync XLib communication
Summary: ScreenEdge::raisePanelProxies() is slow due to sync XLib communication
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.9.90 (Beta 2)
Platform: unspecified Linux
: NOR normal
Target Milestone: 4.11
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/108...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-12 21:18 UTC by Kai Uwe Broulik
Modified: 2013-05-18 18:31 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
mgraesslin: ReviewRequest+


Attachments
glxinfo -l (17.85 KB, text/plain)
2012-12-12 21:19 UTC, Kai Uwe Broulik
Details
kwin supportInfo (5.38 KB, text/plain)
2012-12-12 21:19 UTC, Kai Uwe Broulik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Uwe Broulik 2012-12-12 21:18:54 UTC
With KDE 4.10 Beta 2 Present Windows has become unusably slow for me (probably again some Mesa update Ubuntu shipped that broke everything, again). The transition when the effect starts (ie. all the windows moving and scaling small) is perfectly smooth but once I hover a window or do something in Present Windows, frame rate drops below 1 frame per second.

Affects only OpenGL2 (Xrender works fine, and OpenGL1 is broken here) as well as kwin_gles. VSync on/off has no effect.

Reproducible: Always
Comment 1 Kai Uwe Broulik 2012-12-12 21:19:08 UTC
Created attachment 75804 [details]
glxinfo -l
Comment 2 Kai Uwe Broulik 2012-12-12 21:19:23 UTC
Created attachment 75805 [details]
kwin supportInfo
Comment 3 Kai Uwe Broulik 2012-12-12 21:24:15 UTC
Okay, wrong. When I disable OpenGL2 shaders, then Present Windows works without problems.
Comment 4 Thomas Lübking 2012-12-12 21:42:23 UTC
Set the scale method to "smooth" and try again.
Likely upstream, pot. related to the latter comments in bug #308385
If you can, please try to revert commit 9364f5a7579567f5ebcf537eccf6147416e0e7e0 and report the result.
Comment 5 Kai Uwe Broulik 2012-12-12 21:59:27 UTC
Using "Smooth" works. Is this also related to the window decoration being partially translucent when using OpenGL and exiting Present Windows?
Will try tomorrow.
Comment 6 Thomas Lübking 2012-12-12 22:04:29 UTC
(In reply to comment #5)
> partially translucent when using OpenGL and exiting Present Windows?
Does that also happen if you turn of blurring?
Comment 7 Kai Uwe Broulik 2012-12-12 22:06:19 UTC
(In reply to comment #6)
> Does that also happen if you turn of blurring?
Yes. And when I make animation speed really slow, you can see that title bars are translucent when they move and once they stop, they get opaque again.
Comment 8 Thomas Lübking 2012-12-12 22:25:42 UTC
Not here (nvidia blob) - lanczos or not, glsl or not.
but i've a change to the glsl stack system in the pipe - could be pollution from some other effect.
Does it only happen with "opengl 2 shaders"?
Does it happen right after suspend/resume?
Comment 9 Kai Uwe Broulik 2012-12-12 22:28:42 UTC
Happens only *without* OpenGL2 shaders. With it is fine, without I get the effect. No matter if Lanczos is enabled or not. Happens also if I suspended and resumed desktop effects.
Comment 10 Martin Flöser 2013-01-07 16:55:14 UTC
I have seen this problem also on my desktop system. Thanks for reporting which shows me that there is a problem. Will try to investigate.
Comment 11 Martin Flöser 2013-01-30 08:04:09 UTC
Adding the investigation results. The problem has nothing to do with OpenGL, it's just pure chance by changing the settings.

The problem is ScreenEdge::raisePanelProxies() which performs lots of sync XLib calls which can make the operation slow. I added time measuring debug statements and it showed up to 500 msec spent in this method. It's called when ending a fullscreen effect like Present Windows or Desktop Grid, but not on start.
Comment 12 Martin Flöser 2013-05-18 18:31:42 UTC
Fixed in master