[cairo] Cairo and GdiPlus or two win32 backends

[Hans Breuer]

Owen Taylor wrote:
> On Sun, 2005-01-16 at 23:51 +0100, Hans Breuer wrote:
>>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.)
> 
Please, Carl, get convinced. Including <windows.h> is a nightmare :-)

>>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.
> 
But if we let GDI do it there may be a performance benefit cause it may
map stuff to accelerated functions. [And maybe my eyes are just too bad
to see the difference between the "very rough approximation" and the
real thing.]

> 
>>>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.
> 
Could the backend let Cairo 'know' what part of the image needs to be 
bitmapped ? Playing a little more with the GDI backend and operators I was 
thinking about:
- return CAIRO_INT_STATUS_UNSUPPORTED (from composite_traps)
- get asked for a bitmap with the right size and resolution, i.e extending
   backend::get_image()
- render what is currently already drawn to the internal metafile,
   just PlayEnhMetafile()  for a part of the whole image.
- get Cairo render to this partial image, keep it in the backend and
   output it in show_page()
- than one could either put the bitmap in the metafile and let further
   drawing go over it or keep track of the bittmapped parts and draw twice
   if something gets drawn over the boundaries of it.

Could such an approach work ?

 > [...]
> 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.
> 
It may help avoiding your three-pass rendering model, which sound rather
expensive to me.

 >>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) n 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 point was pure application orientation. Can there be done things
with Cairo which are not possible with other plug-ins? The limitations
to my Cairo backend are not relevant to what Dia does, e.g. it only uses
CAIRO_OPERATOR_OVER cause that's how Dia's drawing model is defined.

But half a year ago and still today there can be no output generated
with Dia/Cairo which Dia couldn't do better with another plug-ins.
[The early rasterization and the lack in font support are relevant.]

For PDF it recently learned to talk to gnome-print again.

 >>
>>   - 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.
> 
As Keith already pointed out it simply is a missing implementation. But
it's there for at least half a year.
And in general I'm not that happy with Cairo's patch acceptance policy ;)

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

Thanks,
	Hans

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