Re: xlib-xcb glitch art
Chris Wilson <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
On Fri, May 22, 2015 at 10:55:41AM +0200, Uli Schlachter wrote: > Hi, > > Am 22.05.2015 um 08:19 schrieb Behdad Esfahbod: > > See: > > http://www.hellocatfood.com/glitch-gimp/ > > https://bugs.freedesktop.org/show_bug.cgi?id=67505 > > 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. It's a trick that permugates from the kernel in order to avoid synchronisation - our buffer management is all or nothing, we don't have subsurface serialisation (and probably not for the forseeable future). And what this allows is for gimp to render directly into video memory using unsynchronised wrties (like glMapBufferRange(GL_MAP_UNSYNCHRONIZED_BIT | GL_MAP_PERSISTENT_BIT)). -Chris -- Chris Wilson, Intel Open Source Technology Centre -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo