Re: cairo x11 surfaces
Hi, by using GNUstep and some apps a bit I can confirm the "mixed" performance of the new backend, something is better, something definitively worse. On my computer at home (FreeBSD/GeForce local X display) I notice visible flickering when watching images full-screen using LaternaMagica and "scale-to-fit" selected. When I display the next image, I clearly see the new image shown correctly, then a black flicker, then re-displayed. Doing the same on my Laptop (NetBSD/i915 local X display) is totally fine. I even exported the display to another host and it displays without flickering and reasonably fast. Very strange! Window-Flickering while resizing is however visible everywhere. Even without solid resizing, I can clearly see that when dragging and re-sizing the window, the only redraw at the final size blanks out white and redraws. Clarly, using live-resizing and repeating this many times will flicker a lot. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Hi If we run in to problems we can switch back to XGCairoXImageSurface before the next release, but it looks promising. In particular, I tried X forwarding to Apple's X11.app, which only supports 24-bit windows, and the new surface is significantly faster than XGCairoXImageSurface, and the alpha channel of images is correctly preserved (unlike XGCairoSurface). Riccardo, this should fix GNUstep on the 16-bit display configuration where it wasn't working for you. If you could test it some time and let me know if it works, that would be great. Right. Exporting do 16-bit displays seems to work quite well. I did not try locally on 16bit yet. I built it on PPC, exported to X11 16-bit, seems to work fine. It works fine locally in 24bit on x86... I did only quick tests. Some operations seem to have become faster. I think definitvely exporting display is better as Philippe reported. Window resizing is definitively slow and flickery, also locally. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
On 14.10.2011 12:01, Philippe Roussel wrote: On Thu, Oct 13, 2011 at 03:26:10PM -0600, Eric Wasylishen wrote: I had a look at implementing it today, and it turned out to be easier than expected so I finished& committed it. If we run in to problems we can switch back to XGCairoXImageSurface before the next release, but it looks promising. In particular, I tried X forwarding to Apple's X11.app, which only supports 24-bit windows, and the new surface is significantly faster than XGCairoXImageSurface, and the alpha channel of images is correctly preserved (unlike XGCairoSurface). Riccardo, this should fix GNUstep on the 16-bit display configuration where it wasn't working for you. If you could test it some time and let me know if it works, that would be great. I tested your modifications briefly yesterday. The gui drawing is now really fast and responsive over ssh, comparable to gtk I would say, but I get a lot of flickering when resizing a windows on a local connection. Same here. It works nice and fast, but window resizing seems to operate worse. It feels slower and has a lot of flickering. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
David Chisnall wrote: > On 15 Oct 2011, at 10:14, Wolfgang Lux wrote: > >> Hi Eric, >> >>> Wolfgang, that's an interesting bug. I couldn't reproduce it with GNUstep >>> running on Ubuntu 10.10 / x86-64 with cairo 1.10.0, exporting the display >>> to a PowerPC iBook running OS X 10.4 and X11.app. What are the details of >>> the setup you tested? My first thought is it might be a cairo bug since >>> cairo handles all of the details of transferring surfaces to the X server >>> with this new surface. >> >> I had tested this with the gnu-gnu-gnu combo built on OS X (Leopard for >> PowerPC, Snow Leopard for x86) and exporting the display to the other >> machine. >> >> I now have updated the Ubuntu 10.04 installation on the PowerBook as well >> and running applications there with the display exported to an x86 machine >> works. So maybe the issue is somewhere in the Cairo libs? On the OS X >> machines I'm using cairo 1.10.2 from MacPorts, whereas on Ubuntu I have >> 1.8.10 installed. > > Are you using Apple's X11, or XQuartz from Mac OS Forge? Apple's X11 is so > buggy that it's impressive that you got it working even with mangled > colours... I'm using Apple's X11 and it has been working for me (almost) without problems for ages now. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
On 15 Oct 2011, at 10:14, Wolfgang Lux wrote: > Hi Eric, > >> Wolfgang, that's an interesting bug. I couldn't reproduce it with GNUstep >> running on Ubuntu 10.10 / x86-64 with cairo 1.10.0, exporting the display to >> a PowerPC iBook running OS X 10.4 and X11.app. What are the details of the >> setup you tested? My first thought is it might be a cairo bug since cairo >> handles all of the details of transferring surfaces to the X server with >> this new surface. > > I had tested this with the gnu-gnu-gnu combo built on OS X (Leopard for > PowerPC, Snow Leopard for x86) and exporting the display to the other machine. > > I now have updated the Ubuntu 10.04 installation on the PowerBook as well and > running applications there with the display exported to an x86 machine works. > So maybe the issue is somewhere in the Cairo libs? On the OS X machines I'm > using cairo 1.10.2 from MacPorts, whereas on Ubuntu I have 1.8.10 installed. Are you using Apple's X11, or XQuartz from Mac OS Forge? Apple's X11 is so buggy that it's impressive that you got it working even with mangled colours... David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Hi Eric, > Wolfgang, that's an interesting bug. I couldn't reproduce it with GNUstep > running on Ubuntu 10.10 / x86-64 with cairo 1.10.0, exporting the display to > a PowerPC iBook running OS X 10.4 and X11.app. What are the details of the > setup you tested? My first thought is it might be a cairo bug since cairo > handles all of the details of transferring surfaces to the X server with this > new surface. I had tested this with the gnu-gnu-gnu combo built on OS X (Leopard for PowerPC, Snow Leopard for x86) and exporting the display to the other machine. I now have updated the Ubuntu 10.04 installation on the PowerBook as well and running applications there with the display exported to an x86 machine works. So maybe the issue is somewhere in the Cairo libs? On the OS X machines I'm using cairo 1.10.2 from MacPorts, whereas on Ubuntu I have 1.8.10 installed. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Thanks for the feedback, everyone. Wolfgang, that's an interesting bug. I couldn't reproduce it with GNUstep running on Ubuntu 10.10 / x86-64 with cairo 1.10.0, exporting the display to a PowerPC iBook running OS X 10.4 and X11.app. What are the details of the setup you tested? My first thought is it might be a cairo bug since cairo handles all of the details of transferring surfaces to the X server with this new surface. Niels: that's interesting. I'll install kde and see if I can figure out why it is slow with compositing enabled. Phillipe, thanks for the update. I noticed some flickering too which I will investigate. -Eric On 2011-10-14, at 5:14 AM, Wolfgang Lux wrote: > Eric Wasylishen wrote: > >> I had a look at implementing it today, and it turned out to be easier than >> expected so I finished & committed it. >> >> If we run in to problems we can switch back to XGCairoXImageSurface before >> the next release, but it looks promising. In particular, I tried X >> forwarding to Apple's X11.app, which only supports 24-bit windows, and the >> new surface is significantly faster than XGCairoXImageSurface, and the alpha >> channel of images is correctly preserved (unlike XGCairoSurface). >> >> Riccardo, this should fix GNUstep on the 16-bit display configuration where >> it wasn't working for you. If you could test it some time and let me know if >> it works, that would be great. > > Nice change. However it has a subtle endianness bug. When the display is on a > machine with a different endianness than the machine running the application > (e.g., PowerPC vs. x86), the colours of all icons are displayed incorrectly. > See the SystemPreferences and Color panel screenshots below. > > Wolfgang > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Hi Eric,
Am 13.10.2011 23:26, schrieb Eric Wasylishen:
> I had a look at implementing it today, and it turned out to be easier than
> expected so I finished & committed it.
>
> If we run in to problems we can switch back to XGCairoXImageSurface before
> the next release, but it looks promising. In particular, I tried X forwarding
> to Apple's X11.app, which only supports 24-bit windows, and the new surface
> is significantly faster than XGCairoXImageSurface, and the alpha channel of
> images is correctly preserved (unlike XGCairoSurface).
This is a nice change; things seem a lot faster now in the normal case.
But (at least for me) it seems to have quite the opposite effect once I
turn on compositing in the window manager (kwin, in this case). I'm
guessing that is because the compositing manager does its own
double-buffering, though the effects are a bit more servere than I would
expect from just that.
A possible workaround would be to check whether a compositing manager
has taken the _NET_WM_CM_S${ScreenNum} [0] selection and avoid the
double buffering in that case. But then we'd also have to keep track of
when compositing is enabled and disabled.
Cheers,
Niels
[0] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552745
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Hi, On Thu, Oct 13, 2011 at 03:26:10PM -0600, Eric Wasylishen wrote: > Hi Fred, > > I had a look at implementing it today, and it turned out to be > easier than expected so I finished & committed it. > > If we run in to problems we can switch back to XGCairoXImageSurface > before the next release, but it looks promising. In particular, I > tried X forwarding to Apple's X11.app, which only supports 24-bit > windows, and the new surface is significantly faster than > XGCairoXImageSurface, and the alpha channel of images is correctly > preserved (unlike XGCairoSurface). > > Riccardo, this should fix GNUstep on the 16-bit display > configuration where it wasn't working for you. If you could test it > some time and let me know if it works, that would be great. I tested your modifications briefly yesterday. The gui drawing is now really fast and responsive over ssh, comparable to gtk I would say, but I get a lot of flickering when resizing a windows on a local connection. Thanks, Philippe -- Un celibataire est un homme qui a rate l'occasion de rendre une femme malheureuse. Jasmine Birtles ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Excellent! Hope to find some time over the weekend to test this. Thank you Fred On the road Am 13.10.2011 um 23:26 schrieb Eric Wasylishen : > Hi Fred, > > I had a look at implementing it today, and it turned out to be easier than > expected so I finished & committed it. > > If we run in to problems we can switch back to XGCairoXImageSurface before > the next release, but it looks promising. In particular, I tried X forwarding > to Apple's X11.app, which only supports 24-bit windows, and the new surface > is significantly faster than XGCairoXImageSurface, and the alpha channel of > images is correctly preserved (unlike XGCairoSurface). > > Riccardo, this should fix GNUstep on the 16-bit display configuration where > it wasn't working for you. If you could test it some time and let me know if > it works, that would be great. > > Cheers, > Eric > > > On 2011-10-13, at 1:08 AM, Fred Kiefer wrote: > >> This sounds very promising. Maybe we can get rid of XWindowBuffer that way. >> Do you think this change should go in before the release or after? >> >> Fred >> >> On 12.10.2011 18:54, Eric Wasylishen wrote: >>> Hi, I just wanted to report on a bit of research I did on this. There was a >>> suggestion on the cairo mailing list [1] to implement double buffering on X >>> by doing the following: >>> >>> - create a cairo xlib surface for the window (could be 32-bpp with alpha, >>> 16-bpp no alpha, etc.) >>> - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As >>> far as I know the resulting surface is guaranteed to have an alpha channel. >>> I skimmed over the implementation and it looks like it tries to create an >>> xlib surface with alpha; if that fails, it creates a 32-bpp image surface >>> and returns that. >>> - when expose events are received, use cairo drawing methods to copy the >>> desired region from the back buffer to the window. This should boil down to >>> a efficient X call if both surfaces are stored on the server, or otherwise >>> cairo should handle using shared memory to transfer the 32bpp image surface >>> to the X server, and converting it to the needed format. >>> >>> Now, I haven't tested this, but it looks like it should work and looks like >>> exactly the behaviour we want, and as a bonus, cairo does all of the >>> messy/hard work. :-) >>> >>> >>> It's amazingly hard to find tutorials on how to set up double buffering. >>> Here's another comment I found: "A conversation with keithp indicates that >>> his current thinking is that the right way to do double buffering is via an >>> explicit copy from a separate pixmap. This is portable to absolutely >>> everywhere, and requires no magic. Probably there will soon be a convention >>> for the compositing manager to handle the double buffering on systems where >>> one is running, since it needs to buffer anyhow. But this would be in the >>> future." [3] >>> >>> --Eric >>> >>> [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html >>> [2] >>> http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar >>> [3] http://xcb.freedesktop.org/XcbNotes/ >> >> >> ___ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Forgot to add, thanks to Matt Rice for sending me some example code of this technique. On 2011-10-13, at 3:26 PM, Eric Wasylishen wrote: > Hi Fred, > > I had a look at implementing it today, and it turned out to be easier than > expected so I finished & committed it. > > If we run in to problems we can switch back to XGCairoXImageSurface before > the next release, but it looks promising. In particular, I tried X forwarding > to Apple's X11.app, which only supports 24-bit windows, and the new surface > is significantly faster than XGCairoXImageSurface, and the alpha channel of > images is correctly preserved (unlike XGCairoSurface). > > Riccardo, this should fix GNUstep on the 16-bit display configuration where > it wasn't working for you. If you could test it some time and let me know if > it works, that would be great. > > Cheers, > Eric > > > On 2011-10-13, at 1:08 AM, Fred Kiefer wrote: > >> This sounds very promising. Maybe we can get rid of XWindowBuffer that way. >> Do you think this change should go in before the release or after? >> >> Fred >> >> On 12.10.2011 18:54, Eric Wasylishen wrote: >>> Hi, I just wanted to report on a bit of research I did on this. There was a >>> suggestion on the cairo mailing list [1] to implement double buffering on X >>> by doing the following: >>> >>> - create a cairo xlib surface for the window (could be 32-bpp with alpha, >>> 16-bpp no alpha, etc.) >>> - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As >>> far as I know the resulting surface is guaranteed to have an alpha channel. >>> I skimmed over the implementation and it looks like it tries to create an >>> xlib surface with alpha; if that fails, it creates a 32-bpp image surface >>> and returns that. >>> - when expose events are received, use cairo drawing methods to copy the >>> desired region from the back buffer to the window. This should boil down to >>> a efficient X call if both surfaces are stored on the server, or otherwise >>> cairo should handle using shared memory to transfer the 32bpp image surface >>> to the X server, and converting it to the needed format. >>> >>> Now, I haven't tested this, but it looks like it should work and looks like >>> exactly the behaviour we want, and as a bonus, cairo does all of the >>> messy/hard work. :-) >>> >>> >>> It's amazingly hard to find tutorials on how to set up double buffering. >>> Here's another comment I found: "A conversation with keithp indicates that >>> his current thinking is that the right way to do double buffering is via an >>> explicit copy from a separate pixmap. This is portable to absolutely >>> everywhere, and requires no magic. Probably there will soon be a convention >>> for the compositing manager to handle the double buffering on systems where >>> one is running, since it needs to buffer anyhow. But this would be in the >>> future." [3] >>> >>> --Eric >>> >>> [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html >>> [2] >>> http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar >>> [3] http://xcb.freedesktop.org/XcbNotes/ >> >> >> ___ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Hi Fred, I had a look at implementing it today, and it turned out to be easier than expected so I finished & committed it. If we run in to problems we can switch back to XGCairoXImageSurface before the next release, but it looks promising. In particular, I tried X forwarding to Apple's X11.app, which only supports 24-bit windows, and the new surface is significantly faster than XGCairoXImageSurface, and the alpha channel of images is correctly preserved (unlike XGCairoSurface). Riccardo, this should fix GNUstep on the 16-bit display configuration where it wasn't working for you. If you could test it some time and let me know if it works, that would be great. Cheers, Eric On 2011-10-13, at 1:08 AM, Fred Kiefer wrote: > This sounds very promising. Maybe we can get rid of XWindowBuffer that way. > Do you think this change should go in before the release or after? > > Fred > > On 12.10.2011 18:54, Eric Wasylishen wrote: >> Hi, I just wanted to report on a bit of research I did on this. There was a >> suggestion on the cairo mailing list [1] to implement double buffering on X >> by doing the following: >> >> - create a cairo xlib surface for the window (could be 32-bpp with alpha, >> 16-bpp no alpha, etc.) >> - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As >> far as I know the resulting surface is guaranteed to have an alpha channel. >> I skimmed over the implementation and it looks like it tries to create an >> xlib surface with alpha; if that fails, it creates a 32-bpp image surface >> and returns that. >> - when expose events are received, use cairo drawing methods to copy the >> desired region from the back buffer to the window. This should boil down to >> a efficient X call if both surfaces are stored on the server, or otherwise >> cairo should handle using shared memory to transfer the 32bpp image surface >> to the X server, and converting it to the needed format. >> >> Now, I haven't tested this, but it looks like it should work and looks like >> exactly the behaviour we want, and as a bonus, cairo does all of the >> messy/hard work. :-) >> >> >> It's amazingly hard to find tutorials on how to set up double buffering. >> Here's another comment I found: "A conversation with keithp indicates that >> his current thinking is that the right way to do double buffering is via an >> explicit copy from a separate pixmap. This is portable to absolutely >> everywhere, and requires no magic. Probably there will soon be a convention >> for the compositing manager to handle the double buffering on systems where >> one is running, since it needs to buffer anyhow. But this would be in the >> future." [3] >> >> --Eric >> >> [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html >> [2] >> http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar >> [3] http://xcb.freedesktop.org/XcbNotes/ > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
This sounds very promising. Maybe we can get rid of XWindowBuffer that way. Do you think this change should go in before the release or after? Fred On 12.10.2011 18:54, Eric Wasylishen wrote: Hi, I just wanted to report on a bit of research I did on this. There was a suggestion on the cairo mailing list [1] to implement double buffering on X by doing the following: - create a cairo xlib surface for the window (could be 32-bpp with alpha, 16-bpp no alpha, etc.) - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far as I know the resulting surface is guaranteed to have an alpha channel. I skimmed over the implementation and it looks like it tries to create an xlib surface with alpha; if that fails, it creates a 32-bpp image surface and returns that. - when expose events are received, use cairo drawing methods to copy the desired region from the back buffer to the window. This should boil down to a efficient X call if both surfaces are stored on the server, or otherwise cairo should handle using shared memory to transfer the 32bpp image surface to the X server, and converting it to the needed format. Now, I haven't tested this, but it looks like it should work and looks like exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard work. :-) It's amazingly hard to find tutorials on how to set up double buffering. Here's another comment I found: "A conversation with keithp indicates that his current thinking is that the right way to do double buffering is via an explicit copy from a separate pixmap. This is portable to absolutely everywhere, and requires no magic. Probably there will soon be a convention for the compositing manager to handle the double buffering on systems where one is running, since it needs to buffer anyhow. But this would be in the future." [3] --Eric [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html [2] http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar [3] http://xcb.freedesktop.org/XcbNotes/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
cairo x11 surfaces
Hi, I just wanted to report on a bit of research I did on this. There was a suggestion on the cairo mailing list [1] to implement double buffering on X by doing the following: - create a cairo xlib surface for the window (could be 32-bpp with alpha, 16-bpp no alpha, etc.) - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far as I know the resulting surface is guaranteed to have an alpha channel. I skimmed over the implementation and it looks like it tries to create an xlib surface with alpha; if that fails, it creates a 32-bpp image surface and returns that. - when expose events are received, use cairo drawing methods to copy the desired region from the back buffer to the window. This should boil down to a efficient X call if both surfaces are stored on the server, or otherwise cairo should handle using shared memory to transfer the 32bpp image surface to the X server, and converting it to the needed format. Now, I haven't tested this, but it looks like it should work and looks like exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard work. :-) It's amazingly hard to find tutorials on how to set up double buffering. Here's another comment I found: "A conversation with keithp indicates that his current thinking is that the right way to do double buffering is via an explicit copy from a separate pixmap. This is portable to absolutely everywhere, and requires no magic. Probably there will soon be a convention for the compositing manager to handle the double buffering on systems where one is running, since it needs to buffer anyhow. But this would be in the future." [3] --Eric [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html [2] http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar [3] http://xcb.freedesktop.org/XcbNotes/ On 2011-09-19, at 4:37 AM, Fred Kiefer wrote: > 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
