Why Cairo for GDK (was Re: [Cairo] Text API proposal)

[Owen Taylor]

[ Cutting down the CC list and responding in two parts to keep
  this manageable ]

On Sat, 2003-08-16 at 04:25, Hans Breuer wrote:
> At 19:56 11.08.03 -0400, Owen Taylor wrote:
> >On Mon, 2003-08-11 at 19:13, Hans Breuer wrote:
> >
> >> >We really have a number of somewhat orthogonal issues:
> >> I have a much more basic question:
> >> 
> >> How is Cairo spupposed to be used in the Gtk+ context and where
> >> are the benefits (not only on win32). 
> >> The only place I currently could imagine benfit from an advanced 
> >> rendering engine is between Gtk and Gdk (or between Gdk 'generic'
> >> and the platform specific backends) which would allow to do 
> >> fancy things like antialiased lines in widgets, rotated text (for 
> >> e.g. verical notebook tabs), etc.
> >
> >The goal is that Cairo completely replaces the GDK rendering API,
> >so that all rendering goes through it. For standard widgets,
> >there may not be that big need for a better rendering API,
> >but:
> >
> > - When you do need more powerful capabilities you'll have them
> > - We'll be able to use the same drawing API for printing
> >   as for display to the screen
> > - We share our cross-platform displaay code with a much broader
> >   set of users. GDI+, OpenGL, Postscript, etc, backends are
> >   all possible.
> >
> This would mean to write Cairo backends based on GDI+ (which IMO
> is only a half baked C++/C# wrapper around GDI), OpenGL etc.
> And almost throw away all the current Gdk backends ?

A) We're not talking about throwing away most of GDK - all we are
   talking about is the rendering part, not the windowing part.
   I'd guess rendering is probably about 30% of a GDK backend.
   And the old rendering would stay there anyways for back-compat,
   at least for a while.
   
B) We don't have OpenGL, Postscript, etc, backends for GDK currently

C) If GDI+ doesn't offer any advantages, then people can write the
   backend for old-fashioned GDI. 

> Still the question arises what would be the benefit for
> cross platform application developers to use Cairo instead of
> the current implementations?

While it's wonderful that you already have code in Dia to handle
lots of different backends, the idea here is to provide a nice
powerful cross platform rendering API in GDK. I don't think 
the answer to "how do I print" and "how do I draw Bezier curves"
should be:

   You #ifdef your code to use Cairo on Linux,  GDI on Windows, and
   Quartz on OS/X. You'll have to create a common API layer over
   those three systems yourself, since that's outside the scope
   of GTK+.

That's not a credible answer. Now, I could try to evolve the current
GDK API's to be a nice Java2D-level modern graphics API and wrap
that on top of anything but:

 - It's not a good fit ... it would be hard to evolve in that way

 - Cairo, by its nature, needs a multi-backend consruction - at least
   RENDER, client-side, and PS, so we might as well reuse that
   virtualization to do cross-platform.

 - Why should we duplicate effort in API design between Cairo
   and GDK?

> >>   It would be nice how Cairo would fit into the picture of
> >>   a high level vector application which tries to provide
> >>   much of the functionality I assume to be the core of Cairo.
> >
> >The idea is that with Cairo dia won't have to have all it's
> >own code for drawing antialiased lines, zooming, etc. You'll
> >have a powerful, flexible drawing API already there for 
> >you.
> 
> Given the number of current output facilities of Dia (gdk,
> libart, svg, wmf, hpgl, gdi to printer (via wmf), two 
> PostScript - one with embedded outlines, xfig, cgm, dxf, wpg)
> this would either mean to write a bunch of new backends
> for Cairo or keep much of Dia's rendering code around.

I don't understand the concern. Sure, you need to keep around
xfig/cgm/dxf/etc, but:

 - You get one backend that works nicely to the screen anywhere
   GDK runs
 - If we do our job well, that same backend works nicely to
   the printer anywhere GDK runs. (But if you want to do a 
   custom Windows-printing code, you could do it.)
 - If we do our job well, that same backend produces pretty
   good EPS files. (But if you wanted to write your own
   EPS generation code you could do it.)

So, first you've eliminated a bunch of your backends, and second,
you've eliminated all the *non-portable* backends. It's possible
to write a program like Dia that just works out of the box
on Windows and X.

Of course, there will always be applications sophisticated enough
to want to do more than we can provide and #ifdef that per-platform,
but I think a powerful cross-platform API that supports printing
has to be considered a good thing.

Regards,
					Owen