Re: Gdk/Cairo integration thought

On 5/10/05, Owen Taylor <[email protected]> wrote:
> On Tue, 2005-05-10 at 09:43 -0400, Mike Emmel wrote:
> > This is slightly off topic to your post but hey :)
> >
> > Are you planning on routing all drawing operations in GDK through
> > cairo ? I would like that since its problematic to mix and I'd rather
> > optimize cairo. I'm running into issues with directfb were the
> > directfb
> > code would like to change the state of the surfaces and it munges
> > cairos state. I'm sure similar situations arise with other backends
> > glitz in particular.
> 
> There are a lot of places where it is hard to get 100% compatibility
> redirecting drawing through Cairo:
> 
>  - Many parts of the GC aren't easily implementable. Even not
>    worrying about pixel exactness, there is:
> 
>     Functions other than GDK_COPY
>     GDK_INCLUDE_INFERIORS
>     Clip masks
> 
Right the other half of my plan was to add these as support functions
or extension functions to the cairo backend of course this would
intially be "my approach" but I suspect each cairo backend may want to
have similar primitive drawing routines.
>    A function like GDK_XOR doesn't even make any sense in Cairo-land
>    since it is defined in terms of pixel bit values, and Cairo only
>    talks colors.
Agian I was thinking that this additional functionality could be
obtained from the cairo backend via a lower level and mabye standard
api.
> 
>  - "graphics exposes" in gdk_draw_drawable() aren't doable with
>    Cairo. There is also a current bug (moderately hard to fix)
>    in Cairo with using a surface as a source for drawing to itself
>    that would trip this up.
> 
>  - gdk_draw_image() isn't implementable with current Cairo since
>    the source format is whatever the X server gives us. Plus,
>    if someone is going through the trouble to use shared memory
>    images, they probably don't want us to bypass that and emulate.
> 
>  - gdk_draw_points() is almost inevitably going to be much, much
>    slower when done through Cairo.
> 
> With that in mind, redirecting all drawing through Cairo before
> it gets to the backend would be a mistake. While most of the
> above don't affect the "average" app, if an app is relying on
> one of those things there is no good reason to break it.
> 
> Conversion to Cairo has various pieces:
> 
>  - I'm busily converting all the GTK+ widgets and GTK+ default
>    theme drawing code to use Cairo instead of gdk_draw_...
> 
>  - A GDK backend that didn't need compatibility with a wide
>    range of existing apps could certainly implement more of
>    gdk_draw_* using cairo. There is even a helper function
>    _gdk_gc_update_context() that can be used and already gives
>    you tile/stipple/clip-region.
> 
> You could also imagine going through Cairo *when* the drawing
> could be done exactly with Cairo. (E.g., h/v-lines, rectangles,
> that don't hit any of the above snags.) I haven't considered
> that a lot ... it might be useful at improving the performance
> of apps that do custom drawing and haven't yet been converted
> to use Cairo.
> 
Okay thanks for the update. I think I need to spend some time looking
at what a "extension" backend  for cairo that exposed some additional
api's to handle cases like you mentioned would look like. I guess I
should have explained a bit better in my orginal email.

Mike

> Regards,
>                                                 Owen
> 
> 
> BodyID:47152663.2.n.logpart (stored separately)
> 
>