Re: Gdk/Cairo integration thought



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

   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.

 - "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.

Regards,
						Owen

Attachment: signature.asc
Description: This is a digitally signed message part



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