discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Status of Cairo backend


From: Fred Kiefer
Subject: Re: Status of Cairo backend
Date: Mon, 02 Jul 2007 14:20:50 +0200
User-agent: Thunderbird 1.5.0.12 (X11/20060911)

Yen-Ju Chen wrote:
> 
> Here is what I found out why cairo loses alpha processing. By
> default, the best depth GNUstep choose to use 24 bit (RGB), not 32
> bit (ARGB). (See  back/Source/x11/context.c bestContext()). So all
> the window are RGB (no alpha). (The buffer is 32-bit, though). 
> Whenever cairo draw into the window straight, it loses the alpha.
> Therefore, it cannot render alpha correctly because the background
> has not alpha at all. Here is the code to find the visual for 32 bit
> (ARGB): 
> http://webcvs.freedesktop.org/xapps/fdclock/findargb.c?revision=1.1&view=markup
> 
> 

Thank you for all these references. I tried them myself on the weekend
and it turns out my graphic card only supports 24 bits :-(
It is a wonderful GeForce4 Ti 4200 from NVidia with 128 MB and up to
yesterday I was quite satisfied with it, even for games (OK, old ones at
least). Until I buy a new one, there isn't much I can do for the
development of 32 bit support in GNUstep.

> (You need to include <X11/extensions/Xrender.h> and link to
> libXrender). I try to put them into bestContext() in context.c, but
> art backend does not display properly. So I guess art backend does
> not expect a true ARGB window. That is one of the reasons I suggest a
> cairo_x11 because it is very easy to break art backend and people
> will complain. But fitting cairo into what art backend does is like 
> fitting a jet engine into a regular car. The ARGB window also provide
> a true transparent. I think that's what Compiz/Berly does.
> 
> There are also many legacy code in x11. cairo_x11 can probably get
> rid of a lot of them, especially the part for dealing with Xwindow
> visual, I guess.
> 

There surely is a lot of lagacy code in the x11 part of the backend.
Most of it isn't even for art, but goes back to xlib or is even not used
there. Perhaps it would be worthwhile to clean this up, by moving the
code to where it is actually needed, but I see no reason for a split of
this module.


> The use of overlap copying is what art backend does. If cairo has its
> own x11 server (cairo_x11), I guess it can try to do a plain
> translation or something else to archive the same goal for scrolling.
> 

Sorry, no idea what you are talking about here. Actually the copying is
the right thing to do and I don't understand why it doesn't work in
cairo. They claim that on the X level it is done correctly.

> 
> I am happy to poke around. But having three render engine (xlib, art,
> cairo) together in x11 make it difficult to figure out which part of
> code is for which one.
> 
> If you have time to make window 32-bit and see whether cairo can draw
> straight on window, I am happy to test and see whether I can find
> solutions for other bugs.

Not at the moment (see above)




reply via email to

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