Hi, I just wanted to report on a bit of research I did on this. There was a suggestion on the cairo mailing list [1] to implement double buffering on X by doing the following:
- create a cairo xlib surface for the window (could be 32-bpp with alpha, 16-bpp no alpha, etc.) - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far as I know the resulting surface is guaranteed to have an alpha channel. I skimmed over the implementation and it looks like it tries to create an xlib surface with alpha; if that fails, it creates a 32-bpp image surface and returns that. - when expose events are received, use cairo drawing methods to copy the desired region from the back buffer to the window. This should boil down to a efficient X call if both surfaces are stored on the server, or otherwise cairo should handle using shared memory to transfer the 32bpp image surface to the X server, and converting it to the needed format. Now, I haven't tested this, but it looks like it should work and looks like exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard work. :-) It's amazingly hard to find tutorials on how to set up double buffering. Here's another comment I found: "A conversation with keithp indicates that his current thinking is that the right way to do double buffering is via an explicit copy from a separate pixmap. This is portable to absolutely everywhere, and requires no magic. Probably there will soon be a convention for the compositing manager to handle the double buffering on systems where one is running, since it needs to buffer anyhow. But this would be in the future." [3] --Eric [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html [2] http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar [3] http://xcb.freedesktop.org/XcbNotes/ On 2011-09-19, at 4:37 AM, Fred Kiefer wrote: > On 19.09.2011 08:49, Riccardo Mottola wrote: >>> Sorry, I was premature to commit that; I was hoping to work on it >>> yesterday but didn't have time, so 'll revert it for now. >>> >>> I did some testing with Riccardo and we found that using >>> XGCairoSurface (so using cairo xlib surfaces) did indeed fix the >>> problem he was observing. >>> >>> By switching to XGCairoSurface we get: >>> - much better drawing performance for X over ssh (tested) >>> - potentially better drawing performance overall (not tested, but >>> reported on the cairo mailing list) >>> - better font rendering (subpixel antialiasing support) >>> - support for running on X servers only supporting 16-bit visuals, >>> whereas XGCairoXImageSurface fails completely >>> - delegate more work to cairo and rely less on XWindowBuffer (e.g. >>> cairo handles shared memory) >> Indeed. Essentially one of the objections that was made to >> XGCairoSurface was transparent windows on non-32bit displays. >> >> My main development workstation is 32bit capable but is set as default >> to 24bit. The same is true for my laptop. >> >> I am able to get the opacity test in GSTest for both surface types on >> 24bit. (I can't get the same compositing effect to work with the alpha >> channel of NSColor in neither cases). >> >> So essentially, I found no problems on 24bit and on 16bit the situation >> improved a lot. Most probably without image caching it would have worked. >> >> Eric still hoped to find a buffer which would abstract the depth level, >> but apparently art doesn't use that either. >> >> Did you have any problems with XGCairoSurface, Fred? > > No, and I never said so. I just wanted to know the reason why Eric made a > commit he had argued against. I am working with 32 bit visuals and things are > OK either way on my machine. > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev