Excellent! Hope to find some time over the weekend to test this. Thank you Fred
On the road Am 13.10.2011 um 23:26 schrieb Eric Wasylishen <ewasylis...@gmail.com>: > Hi Fred, > > I had a look at implementing it today, and it turned out to be easier than > expected so I finished & committed it. > > If we run in to problems we can switch back to XGCairoXImageSurface before > the next release, but it looks promising. In particular, I tried X forwarding > to Apple's X11.app, which only supports 24-bit windows, and the new surface > is significantly faster than XGCairoXImageSurface, and the alpha channel of > images is correctly preserved (unlike XGCairoSurface). > > Riccardo, this should fix GNUstep on the 16-bit display configuration where > it wasn't working for you. If you could test it some time and let me know if > it works, that would be great. > > Cheers, > Eric > > > On 2011-10-13, at 1:08 AM, Fred Kiefer wrote: > >> This sounds very promising. Maybe we can get rid of XWindowBuffer that way. >> Do you think this change should go in before the release or after? >> >> Fred >> >> On 12.10.2011 18:54, Eric Wasylishen wrote: >>> 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/ >> >> >> _______________________________________________ >> 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev