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?