Re: [Gnustep-cvs] r33849 - in /libs/back/trunk: ChangeLog Source/cairo/CairoContext.m
On 19.09.2011 08:49, Riccardo Mottola wrote: 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? No, and I never said so. I just wanted to know the reason why Eric made a commit he had argued against. I am working with 32 bit visuals and things are OK either way on my machine. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r33849 - in /libs/back/trunk: ChangeLog Source/cairo/CairoContext.m
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
Re: [Gnustep-cvs] r33849 - in /libs/back/trunk: ChangeLog Source/cairo/CairoContext.m
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
