[cairo] insufficiency of gdkcairo

[Vladimir Vukicevic]

Owen can probably reply more authoratitively, but AFAIK it's not
possible to fix this without breaking backwards compatability with GTK
2; this will probably only be possible with a backwards compat break
with GTK 3.  The problem is that many gtk programs assume things about
the underlying implementation; that is, they use native X calls when
running under X11, and assume that they can pull out a Drawable/Pixmap
from a GdkPixmap, etc.   I'm pretty sure that the gtk folks want to
get to a mostly-cairo world for any drawing... but it's not possible
to do so right now, so it's happening in incremental steps.

- Vlad

On 1/19/06, Jason Dorje Short <jdorje at users.sf.net> wrote:
> I have several questions about gdk-cairo and cairo<->GTK integration,
> and some comments about why I believe it to be incomplete for programs
> using GTK.
>
> My first question is about using drawables with an alpha level.  In old
> GTK and X code, a drawable (GdkPixmap or Pixmap) did not have any alpha
> level.  At some point GTK worked its way around this by using
> GdkPixbufs.  Now all of gdk is supposed to be cairo-based.  Does this
> mean a GdkPixmap can have transparency?  You'd think that it would, but
> evidently not.
>
> (Side note: looking at the GDK 2.8.10 code, I see that GDK is not
> actually cairo-based.  I had assumed that GdkPixmap was just a wrapper
> for cairo_surface_t, so that internally all GDK operations were just
> wrappers for cairo ones.  It would seem to me this is by far the best
> way to do it.  What's actually done is the old method of having
> different types of Pixmaps is still around, and gdkcairo just delves
> into the appropriate backend to get it to create a new cairo_surface_t
> for that pixmap.  This is something I'd say should definitely be
> changed.  With cairo to provide the different backends there is no need
> for GdkPixbuf to have different backends itself!)
>
> So then we are still stuck with using GdkPixbufs for transparency.  The
> problem here is that there is no way for GdkPixbuf to interact with a
> cairo surface that I can see.  The only way is to make a new
> cairo_surface of whatever type and copy the pixbuf data into it (or vice
> versa).  This is a major problem because the majority of the GTK api is
> based entirely on Pixmaps and Pixbufs, and there is, therefore, *no way*
> to use cairo within GTK to do drawing with transparency.  This means,
> basically, that Cairo is not useful within gtk 2.8, and there is no
> incentive for programs to use it except to be able to access a few toy
> drawing operations.
>
> So the next question is: what is needed to fix this?
>
>  From the GTK user's point of view, the basic thing that's needed is for
> GDK to be able to make GdkPixmaps that have alpha levels.  The problem
> with this is two-fold however.  First, all the rest of the GDK API
> assumes that these pixmaps have no alpha, and some may no longer make
> sense with an alpha-supporting Pixmap.  Perhaps a bigger problem is that
> the GDK *backend* also assumes that pixmaps have no alpha, and since the
> GDK backends are not cairo-based this could be a major problem.  Some
> GDK backends may not even support alpha levels; if they were cairo-based
> this could easily be sidestepped by using image surfaces instead but
> since this isn't the case that problem would be insolvable.  The end
> result would be that GdkPixbuf would become obsolete, replaced by
> GdkPixmaps that have alpha support.
>
> An alternative solution from the user's PoV would be to add direct cairo
> support into the gtk/gdk API.  Then gdkcairo would have to be able to
> create a cairo_surface_t directly (the gdk backend would create one of
> the appropriate type; i.e., gdk-x11 would create a cairo-x11 surface).
> Further, all places in the GTK and GDK apis which currently take a
> Pixmap or Pixbuf (and there are lots of them - like gtk_list_store_set
> or gtk_window_set_icon) would have to have variants that take a
> cairo_surface_t.  This would require much greater API changes (many API
> bits which are currently duplicated for Pixmaps and Pixbufs would become
> triplicated).
>
>  From a design point of view, the solution is to get rid of the
> different gdkpixmap backends.  All gdkpixmaps should just be cairo
> surfaces, created to be an appropriate type (possibly the only backend
> function needed).  In the long run this would greatly simplify the GDK
> drawing code since it wouldn't have to worry about platform issues at
> all - cairo would do all the work.  However it will take lots of work to
> make this change, and cairo might not actually be up to the task (gdk
> has a linux-fb backend, but I don't think cairo has one).
>
> -jason
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>