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