Re: [Gnustep-cvs] r33849 - in /libs/back/trunk: ChangeLog Source/cairo/CairoContext.m

[Riccardo Mottola]

Hi,
> 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?

> The only problem with XGCairoSurface is it might not be able to create a 
> surface with alpha - it might be 32-bit argb, 32-bit no-alpha, or 16-bit 
> no-alpha. However, e.g. locking focus on an image is one place in gui where we 
> need a surface with alpha, even if the window server doesn't support alpha.
locking focus was right the problem that GWorkspace was having a couple 
of days ago.


Riccardo