[cairo] Cairo and GdiPlus or two win32 backends

[Hans Breuer]

On 06.02.2005 21:37, Owen Taylor wrote:
> On Sun, 2005-02-06 at 14:05 +0100, Hans Breuer wrote:
>>So your backend is far away from the real thing?
>>Interesting, mine as well ...
> 
> 
> For the case of drawing to a window or bitmap, my backend is, in my
> opinion, "the real thing". Yes, there is more optimization that could
> be done, but it doesn't perform horribly and gives the correct output
> for all inputs.
> 
See below, I'don thinks so, i.e. missing 'logical (path) operators'.

> For drawing to a Windows metafile or a printer, there's significant
> infrastructure work to be done to get a correct mix of image fallbacks
> and vector GDI calls. As far as I can see, that infrastructure isn't
> there in your patch either. You've done a lot of work to implement the
> vector GDI calls, which is important reusable work, but I can't see how
> you can handle something simple like:
> 
>  Draw a path in black
>  Draw on top of that path with 50% alpha on a device not 
>    supporting AlphaBlend
> 
> Because in that case, you have to be able to go back and *redo* the
> path as an image based on later drawing operations. That's what is
> going to require the real work.
> 
There is disabled and wrong code in my patch for 
_cairo_win32_surface_acquire_dest_image() but the comment should be
right. And it should be possible to re-render part of the metafile
into a memory DC to initialize the image to be returned.

>>>There's already a vector-based backend in CVS, the PDF backend. 
>>
>>Which produces similar wrong results for the logical operators
>>at the moment (or better does not handle them at all). My recent
>>patch had some experimental code to at least provide some of IN, OUT,
>>OVER_REVERSE, XOR done by maintaining two "clip" regions internally,
>>the already drawn and the current one.
> 
> 
> I don't actually know what you mean by logical operators. If you
> mean the blending operators of cairo_set_operator(), then they are
> only "logical operators" when you have bi-level alpha. 
> 
If you look at the difference of Cairo/win32 and say Cairo/png for
operator IN, ATOP, ATOP_REVERSE, ... you'll notice it. There
are operators which are purely a combination of pixels and others
which also need to take the clip region of previously drawn stuff
into account. [ You probably can copy the clipping stuff from my
wmf based backend ;-]

> But that is something missing from the fix I put in. Fixed as well.
> 
> 
>>  static cairo_status_t
>>
>>And it is even worse than in the ft2 case, cause it is trying to
>>free an address on the stack, not what is locally allocated (*glyphs)
> 
> 
> As far as I know, it is OK now. If you want to check the CVS version
> to make sure you agree, that would be appreciated.
> 
Works fine.

>>My plan is something like: let the different backends grow independently
>>(with different top priorities) and at some point in time if all tasks
>>can be fulfilled by one of them simply drop the other.
>>
>>Constantly having to merge these experimental highly fluid backends
>>would give m ore confusion and bugs than benefits. Even more if one
>>is to be kept beside public version control.
> 
> 
> I'd like to think we could agree on something, but in the end 
> what you work on, is, of course, up to you. 
> 
At least we agree on your backend being useful ;-) At the moment
I'm not that impressed by the performance though. If Gtk+ 2.8 will
be using lots of Cairo my current notebook will again feel too slow,
like the previous one did with Gtk+-2.0 ...

And as already noted I'm not yet convinced that inventing an own
metafile format is the way to go, so I'll probably update my
backend to show it can be done with Windows metafile as well.

	Hans

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