[cairo] Cairo and GdiPlus or two win32 backends

[Owen Taylor]

On Sun, 2005-01-16 at 23:51 +0100, Hans Breuer wrote:
> 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.

I think it causes quite a few problems to have multiple backends in
play. I certainly don't want to have fonts different for different types
of surfaces ... to have "you can't use that font with that surface"
errors. 

It might be possible to have multiple font backends around that could be
mixed and matched with different surfaces. Any font on any surface.
That wouldn't be that hard to implement from where the code is now.

But the simplest thing, and what I'd like to try to start with is to
simply have one font system for everything. That's how I've set up
PangoCairo. It should allow a pretty rich set of operations ... text
to images, text to paths, etc.

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

I still have to convince Carl on the issue, but yes, I believe the
current situation where cairo.h drags in every header under the sun
is a really bad one. (One of the GTK+ tests programs broke on a
variable called 'rand', because cairo.h dragged in stdlib.h.)

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

Note "on-screen" rendering above. For the screen, we don't have a
distinction between "vector-based" and "pixel based", it's just a
question of whether we are converting vectors to pixels or whether
GDI or GDI+ is converting vectors to pixels. GDI is going to produce
a very rough approximation to what we want onscreen. GDI+ is a bit
better, but still a long ways from the actual Cairo rendering model.

> > 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 ;)

Well, what we have to do in the end is use GDI rendering calls to render
things that work within the GDI (like solid colors paths), and then
use images for what the GDI can't handle.

The technique I was thinking of for that is to output to a (Cairo)
metafile, keeping track of the areas of the screen that can't be handled
within the GDI. Then replay that metafile twice, once to draw what can
be handled by GDI, and once to draw thae parts that can't be handled by
the GDI.

If you know that the output is a printer, you can be more liberal about
what "handled by the GDI" means. Bezier curves without antialiasing will
be fine.

Using GDI+ pushes the boundary between what we handle and what Windows
handles a little further toward Windows. But we still need the logic
described above because GDI+ doesn't handle anything. And assuming that
GDI+ doesn't have hooks to the printer driver layer then we get 
three-part rendering.

 - Part we do as images
 - Part GDI+ does as images
 - Part done as vectors sent to the printer

Which is just a big invitation for rendering inconsistency.

(Some of the GDI+ documentation indicates that it might special-case
PS printers and generate Postscript directly to do a little better than
what the GDI allows. Perhaps gradients? But that's still an incremental
improvement.)

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

I just don't see what using Windows metafiles buys. Enhanced metafiles
are only "enhanced" by adding in newer features of the GDI as compared
to the definition of the original metafile format. They don't give any
features beyond the GDI.

> 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.
What's the point of having a Cairo backend that randomly doesn't do
parts of the Cairo API? People have to switch and use some entirely
different backend? That sounds like Pango :-).

> 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)

The backend API isn't set in stone. It intentionally isn't going to be
public for Cairo-1.0 because it isn't clear exactly what is needed for
every backend.

>    - does not support dashed bezier lines [3]

Since it's in the API, I'm sure patches to fix whatever problems there
are will be accepted.

>    - 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]

Adding GdkPixbuf format to libpixman is going to be a decided pain, but
I think it should be possible. And I want to do it, so that people using
GTK+ aren't constantly having to format-convert.

Cairo's handling of data passed in by the user is generally not nice,
whether it's pixel data, FILE *, or FT_Face. I think it needs general
reworking to add GLib/GTK+ style destroy notifiers.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050116/669b35f4/attachment.pgp