[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of Cairo backend
From: |
Yen-Ju Chen |
Subject: |
Re: Status of Cairo backend |
Date: |
Sat, 30 Jun 2007 17:30:28 -0700 |
On 6/30/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
Thank you for asking about the cairo backend. Sometimes it feels like I
am the only one interested in this and on the even worse days I am quite
happy about that :-)
There has been a bit of progress for this backend this year, but much
less than I expected. We are now able to use the cairo functionality to
produce PS output, but this still does not work completely and I have
postponed the addition of PDF output until this is fixed.
Most of the composite operators now work, but highlighting is still not
implemented and scrolling still doesn't work in all cases.
There are two issues with scrolling, one is that cairo seems unable to
handle overlapping copying. This may be worked around by using an
intermediate surface. Perhaps it would even be sufficient to use a group
here. Anybody with some cairo knowledge willing to test this?
The other problem is worse, as it shows that our composite operation is
not correct. Scrolling in flipped views doesn't work at all. Fro me this
is the biggest show stopper for the cairo backend and your work around
by redrawing the whole scrollview is just this, a workaround.
Having a cairo backend for MS Windows would surely be nice, but is not
worth the effort until the x11 backend is working correctly.
Splitting up the x11 part of the backend to better support cairo is nt
needed in my view. I don't see anything that we could gain by this
split. The buffer we use for art and cairo is something we added later
on and which could be simple removed again by changing the
GSSetDevice::: on CairoContext. But when using an X window directly here
we loose all the alpha handling. There must be a way to get an X window
where cairo does proper alpha processing, but I never found out how.
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
(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.
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.
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.
Have fun
Yen-Ju
All this problems (and the others that I did forget to mention) should
not stop you from testing the cairo backend from time to time and if
possible even contribute code to it.
Cheers,
Fred
Yen-Ju Chen wrote:
> I am curious how experimental the cairo backend is now ?
> The last time I tried, it works mostly fine, except the scrolling problem,
> which can be worked around by always scrolling a full view instead of
> a fraction of view,
> because it will trigger a full redraw than copying one fraction of
> view to another place.
> Is there any other known show-stopper bug ?
>
> Another thing I am wondering is that currently,
> cairo backend try to do whatever art backend do.
> So here is the combination of backend:
>
> x11+xlib
> x11+art
> x11+cairo
> win32+winlib
>
> Considering cairo is a cross-platform solution,
> it can theoretically do
>
> x11+cairo
> win32+cairo
>
> I wonder whether it would be easier to have a stand-alone x11 server
> for cairo, like this:
>
> cairo_x11 + cairo_render, and in the unknown future
> cairo_win32 + cairo_render (I don't really care about this one :).
>
> In that way, cairo_x11 + cairo_render can take advantage of cairo
> without worrying breaking art backend.
> For example, I remember cairo currently write image into a buffer
> shared with art backend.
> If there is a cairo_x11, it can by-pass this buffer and draw straight
> onto window,
> which may (or may not) make things easier.
> To me, cairo backend and art backend are roughly equivalent.
> x11+xlib is for old or slow machine, probably also remote one.
> If a machine can run x11+art, I think it can also run
> cairo_x11+cairo_render.
> So once cairo backend is stable, art backend is not useful anymore.
> Therefore, it makes sense to me to have a window server (cairo_x11)
> exclusively for cairo backend (cairo_render),
> if it helps the adaptation of cairo backend for regular users.