[cairo] xlib-xcb glitch art
psychon at znc.in
Fri May 22 01:55:41 PDT 2015
Am 22.05.2015 um 08:19 schrieb Behdad Esfahbod:
AFAIR Chris made gimp create a shm-backed image surface, properly flush, then
change, then mark it dirty and use it as a source. Then it modifies another part
of the surface without calling mark_dirty() again and expects the new stuff to
be drawn. I understand our API documentation as "always call mark_dirty after
modifying the image surface outside of cairo" while Chris thinks this should work.
What happens with cairo-xlib:
Some special-case XRender-based code can use XShmCreatePixmap to create a pixmap
backed by the shared memory, create a picture for it and draw from it. I don't
know what cairo-xlib does when SHM or XRender is not available, but likely it
won't be fast.
What happens with cairo-xcb:
No support for xcb_shm_create_pixmap() (yet?) and this code instead tries to be
clever in a bad way. It uploads the whole image surface (possibly through shm)
to a pixmap, creates a cairo surface for it and attaches it as a snapshot to the
original image surface.
If you remove the call to _cairo_surface_attach_snapshot from
_cairo_xcb_surface_picture(), the glitch disappears (and lots of other issues, too).
So if you want to fix this, remove most of this surface snapshot stuff from
cairo. It only ever seems to cause issues...
Sadly I didn't have enough time to work on cairo. My long-term plan is to merge
cairo-xcb and cairo-xlib into something like cairo-x11 that then calls "the
right thing" based on the type of cairo_device_t. However, this isn't really easy.
> What's the status of xlib-xcb? Should we fix it or kill it?
Feel free to fix it if you know how. I am still not convinced that cairo-xcb is
actually wrong here...
"Every once in a while, declare peace. It confuses the hell out of your enemies"
- 79th Rule of Acquisition
More information about the cairo