MIT-SHM shared pixmaps are used by GTK to keep some pixbuf caches out of framebuffer when they're going to have Render calls done from them that would have been slow in XAA. There's no performance win for EXA in having a SHM pixmap and avoiding migration, so we really don't want to let people achieve this. If we disable the CreatePixmap shmfunc, it will get us that, while still allowing the SHM PutImage that avoids wire transfers. (We could also accelerate SHM PutImage some more, but I'll leave that for later if we care). The fallbacks caused by these render operations from SHM pixmaps hurt our compositing performance significantly, which is why I really want them to go away. This patch is uncommitted, because it results in misrendering on my radeon that I haven't tracked down yet.
Created attachment 5512 [details] [review] Patch to disable sharedPixmaps.
Bug #6819 covers the rendering issue -- I consider this committable now but haven't yet.
This could be pushed now?
Pushed to master as commit 6b1e354dbb6e8ed9f2c654bbe7f8bbf241843d1c .
This is misunderstanding of the reasoning of the GTK+ ues The *main* reason for the use of shared pixmaps is to improve the speed and robustness of fetching data back from the server. CopyArea => good semantics (off screen data undefined) GetImage => bad semantics (off screen causes X error) When shared memory pixmaps are missing, GTK+: - Grabs the display - Does an XTranslateCoordinates call to figure out where the window is so it can clip - Does the GetImage - Ungrabs So, this is a significant slowdown. However, fetching data back from the server is mostly just a screen-shot thing these days (it was originally used to do alpha-compositing when the RENDER extension was missing, not relevant with EXA.) So, the change may be fine - and if the end result of EXA compositing from a system-memory-locked pixmap is slower than PutImage to a temporary pixmap - a good thing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.