|
From: | Fred Kiefer |
Subject: | Re: cairo xlib surface |
Date: | Wed, 14 Sep 2011 10:04:47 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.22) Gecko/20110907 SUSE/3.1.14 Thunderbird/3.1.14 |
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 :-)
[Prev in Thread] | Current Thread | [Next in Thread] |