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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev