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
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
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.