gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Wasylishen
Subject: Re: [Gnustep-cvs] r33849 - in /libs/back/trunk: ChangeLog Source/cairo/CairoContext.m
Date: Sun, 18 Sep 2011 14:34:35 -0600

Hi Fred,

On 2011-09-18, at 5:20 AM, Fred Kiefer wrote:

> On 17.09.2011 01:56, Eric Wasylishen wrote:
>> Author: ericwa
>> Date: Sat Sep 17 01:56:01 2011
>> New Revision: 33849
>> 
>> URL: http://svn.gna.org/viewcvs/gnustep?rev=33849&view=rev
>> Log:
>> * Source/cairo/CairoContext.m: Switch to XGCairoSurface by default,
>> because it fixes the corrupted display problem reported by Riccardo
>> on 16-bit displays.
>> 
>> Modified:
>>     libs/back/trunk/ChangeLog
>>     libs/back/trunk/Source/cairo/CairoContext.m
> 
> I am surprised you made this change. After your last mails on the mailing 
> list I thought you had given up this idea, as the problems are about as big 
> as the benefits. Could you please explain what changed your mind?
> 
> Fred

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)


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. 

What I wanted to do is extend XGCairoSurface so it can always create 32-bit 
ARGB surfaces, by delegating as much of the work to cairo as possible:
- create a cairo xlib surface at whatever depth the X server supports. If it 
supports alpha, we can use it directly, otherwise we can:
    - create a 32-bit ARGB cairo image surface
    - use the ARGB image surface as the destination for drawing, and use cairo 
to copy regions of the image surface to the xlib surface when it is time to 
display the window.

This will probably be slow, so we won't want to try to do image caching as a 
performance optimization unless the server actually supports native 32-bit 
surfaces. However, it should be fairly simple to implement, produce correct 
output, and should work on any X server.

Eric


reply via email to

[Prev in Thread] Current Thread [Next in Thread]