On 14.09.2011 05:35, Eric Wasylishen wrote:
Three possible solutions I can think of are:
1.
- fix NSImage so if NSWindow's with alpha can't be created, it won't try to
cache images with alpha channels in windows.
- use XGCairoSurface regardless of the available visuals, so windows may or may
not support alpha channels depending on the X server.
2. use XGCairoSurface if the server supports 32-bit visuals, otherwise use
XGCairoXImageSurface. This means we have to deal with two possible code paths
chosen at runtime, though.
3. just leave the code as-is and always use XGCairoXImageSurface.
I think I prefer the first solution, but I'm not sure.
Replying to myself… just noticed apple's docs promise that an
NSBackingStoreBuffered window will have an alpha channel, so my proposal 1)
wouldn't work.
OK, this rules out your proposed solution. (Although application code
should remember to use NSBackingStoreNonretained for faster drawing)
We now still have to solve the original problem that the parameters we
pass into cairo_image_surface_create_for_data() are wrong for 16 bit
display depth. (Or rather the ones we pass into the XWindowBuffer, which
then gives wrong values later on)
Maybe a complete of the whole XWindowBuffer mechanism will be simpler
than trying to understand how it currently worls :-)
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep