XShmCreatePixmap() as copy dest for XCopyArea()
Adam Jackson
ajax at nwnk.net
Wed Jul 8 15:27:32 UTC 2020
On Tue, 2020-07-07 at 13:13 -0700, xorg at pengaru.com wrote:
> Hello list,
>
> I'm trying to use XShmCreatePixmap() in combination with XCopyArea()
> to achieve something resembling an XShmGetSubImage() for copying
> damaged areas piecemeal out of the root window into a shmseg for a
> screencap tool.
MIT-SHM pixmap support is optional, and often not supported because for
most modern X drivers it's a pessimization. I think there happens to be
a bug in glamor where we claim to support shm pixmaps but don't
actually implement it correctly; does your test case work if you
disable acceleration in xorg.conf?
> It seems like no matter what I do, the XCopyArea() never actually
> writes to the shmseg. If instead I use XShmGetImage() with the same
> source drawable (root) and an XShmImage created from the very same
> shminfo as the XShmPixmap, my shmseg gets written to just fine - but
> it fills the entire XShmImage on every update which I'd like to
> avoid.
XShmGetImage is an awkward API, yeah. The width and height of the image
to download are derived from the XImage, not the drawable; if you
create a shm segment exactly as large as the region you want to copy
it'll do what you want. See the source (sigh) for more details:
https://gitlab.freedesktop.org/xorg/lib/libxext/-/blob/master/src/XShm.c#L373
Strictly speaking, you can just munge image->{width,height} before
sending the request instead of creating a new one, you'll just have to
compensate for that when you read the pixels back out of it.
- ajax
More information about the xorg-devel
mailing list