Re: Gdk/Cairo integration thought

On 5/10/05, Owen Taylor <otaylor redhat com> 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
>     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
>  - "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.


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

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