[cairo] Cairo and GdiPlus or two win32 backends

[Hans Breuer]

Owen Taylor wrote:
> On Sat, 2005-01-15 at 23:20 +0100, Hans Breuer wrote:
> 
>>As there still seems to be no consensus if a Cairo/win32 backend
>>should be implemented on top of GDI+ or GDI I've modified the GDI+
>>backend to build side by side with my plain GDI backend.
> 
> I've been working over the last few days on redoing the font code so it
> will be more friendly to native-Win32 fonts. 
Nice to hear that, it'll help my vector based approach as well. Does it also 
incorporate something which would allow to have backend specific font 
backends? e.g. The GIMP currently uses GTK's Pango engine just for GTK's 
business (menus and dialogs), every Gimp specific text processing is done on 
top of freetype/fontconfig cause they provides a richer api.

> Once that is done, my
> thought was to start from scratch and write a win32 backend that:
> 
Yeak, everybody should write his own win32 backend :-) If at the end one or 
two working ones get included with Cairo.
>  - Uses only GDI types in the interface (I don't see mixed
>    GDI+/Cairo rendering as interesting, so there's no reason
>    to constrain implementation in the API)
> 
You don't plan to include <windows.h> in cairo.h, do you? Otherwise I know at 
least one gtk application which will break into many pieces due to namespace 
clashes.

>  - Implements pretty much everything with image fallbacks
>    (text being partially an exception)
> 
> Accelerating solid rectangle fills and "over" alpha blends should be a
> pretty trivial extension from there. I think that approachwill give
> decent performance for on-screen rendering.
> 
That's where our approaches differ. When I think of "high-quality [...] print 
output" the last thing I think of are pixels. First there should be vectors 
and glyphs. When starting the metafile based backend I was convinced it would 
be possible to provide just one more pixel based backend. But I'm still not 
convinced a more high level approach with Cairo is feasible.

> Getting good results for printing is going to be more work ... there's
> some ideas in my last long mail.
> 
At least from my understanding this would be an as much as possible vector 
based (metafile) approach? The idealized programming model on windoze is get 
it working to a DC and you'll get printing almost for nothing. Though with so 
called GDI printing the rasterization does take place on the PC anyway. So if 
one does not care for the huge amount of resources needed the 
everything-becomes-a-pixel paradigm of current Cairo fits quite well ;)

> I'll take another look at your patch before I start doing work on that;
> it didn't really look quite like where I wanted to go in a brief look
> earlier; I'm not quite sure how the use of windows metafiles fits in
> with getting efficient to-screen rendering going. And I think it's
> important to cover the full range of Cairo, and optimize from there
> rather than starting from a subset and later filling in. But I may have
> misunderstood it.
> 
Efficiency is a little unclear to me at the moment. I expect rendering 
metafiles to be quite well optimized though. They are basically a stream of 
function calls with parameters. But as noted above: IMHO the Cairo backend 
interface does not fit that well with vectors, so even the generated 
metafiles become rather huge (I'd like to get on the vectors before the 
"early trapezoidization" [1] takes place.)

Your description of my approach sounds quite right. I like to word it 
differntly though : Get Cairo to do what already can be done with existing 
code. If that fails there appears to be not much point (at least not for me) 
in going any further.
My dia-cairo page [2] compares the output of Cairo with the output of other 
already existing plug-ins. The nice thingh here is the simple ability to 
compare Cairo to most of it 'predecessors' :

* Cairo
   + would allow much more eye candy (not that relevant for Dia though
     cause there is almost no transparency in Dia yet)
   + probably has the nicest API (but IMHO only for application developers,
     not for Cairo backend implementaion)
   - does not support dashed bezier lines [3]
   - cairo_surface_create_for_image() require a pixel format incompatible
     with gdk-pixbuf and also insist to keep the data allocated by the
     API user [3]

* Gdk (Cairo is supposed to be *the* Gtk+ drawing api) :
   + produces better bitmap rendering through gdk-pixbuf
   + already has PangoLayou rendering based on the native font engine

* Libart
   - no text support

* GnomePrint
* wmf + native printing (Cairo is supposed to become the high level
   printing API for Gtk+ applications) :
   + preserves bitmaps with there original resolution (what you see
     is what you had)
   - requires win32

Thanks,
	Hans

[1] http://lists.freedesktop.org/archives/cairo/2005-January/002604.html
[2] http://hans.breuer.org/dia/dia-cairo.htm
[3] http://lists.freedesktop.org/archives/cairo/2004-May/001466.html

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert