[cairo] Cairo and GdiPlus or two win32 backends

[Owen Taylor]

On Sun, 2005-02-06 at 14:05 +0100, Hans Breuer wrote:
> On 06.02.2005 06:45, Owen Taylor wrote:
> > On Sat, 2005-02-05 at 20:26 +0100, Hans Breuer wrote:
> > 
> >>Another attempt for a short summary :
> [...]
> > 
> >>(2) Windows Metafiles can be 'rendered' to anything between file, screen
> >>     and printer. They are also commonly used as clipboard exchange format.
> >>(3) Device Independent Bitmap, that is completely pixel based.
> > 
> > 
> > The interface in my backend is that you pass in a HDC when creating the
> > surface. The surface figures out rendering from there.
> > 
> > Currently, if you are rendering to a metafile or a printer, it's going
> > to fail if you draw anything but text since the fallback rendering
> > relies on BitBlt from the destination DC to a DIB. That's fixable
> > and needs to be fixed, but it is going to require a lot of work.
> > 
> 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.

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.

> > Note that Windows metafile-targeted rendering will *not* give native
> > quality, and is going to involve image fallbacks in many cases.
> > For paths you can use non-AA primitives and it will just look ugly.
> > (On the screen; printer output will be fine.) 
> Let's pretend for a moment that I was always targetting printers with
> my backend ;-)
> 
> > But for many other parts
> > of Pango you can't even approximate the right results.
> > 
> If you expect the real world use of Cairo has equally distributed
> operator coverage, you are probably right.
> But again: I think my choosing of Dia as real world sample wasn't
> that bad - at least not if Cairo does care for 'legacy' vector
> apps. And there is only OVER needed (or is it SRC) without
> transparency. With that use case in mind my approach worked out
> quite well.
>
> And it shouldn't be hard to add more image fallbacks - in fact
> I've done it with the recent patch.

I don't think the way you are adding image fallbacks is going to work.
See above.

>  > [...]
> >>- Is a vector based backend something considered useless or -
> >>   if not - will there be better support in the backend interface ?
> >>   - Extracting clip masks from bitmaps certainly is possible but
> >>     shouldn't this info better be provided as vectors?
> >>   - If I understood the operators correctly they are a mix between
> >>     simple drawing mode and some logical operations on objects. Again
> >>     wouldn't it be possible to provide this objects vector
> >>     information down to the backend?
> > 
> > 
> > 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. 

> > The way that clips are represented to the backend is, yes, pretty
> > clearly not right for such a backend. You could, with sufficient
> > cleverness, avoid rasterizing the trapezoids with the current
> > interface but it should be possible to come up with something easier.
> > 
> > While in a few cases operations done with temporary surfaces could
> > be represented as logical operations on path, doing optimizations
> > in that area is hard because logical operations on vector paths are hard
> > to implement efficiently and robustly.
> > 
> > And many operations done with temporary *can't* be represented
> > as logical operations on paths. So, it seems something best left
> > until there is a reasonable sized sample of programs using Cairo
> > out there to figure out which paths really do need to be optimized.
> > 
> How should such a 'resonable sized sample' look like? Maybe it
> already exists with a cairo based svg viewer?

I don't know a lot about how libsvg works and uses temporary surfaces.
If it's using temporary surfaces to do logical operators on paths,
then perhaps it simply needs to be fixed to do the computational 
geometry itself. 

Or perhaps we need to expose such operators in Cairo directly,
Trying to reverse engineer:

 mask = cairo_surface_create_similar (surface, ... CAIRO_FORMAT_A8);
 [ clear mask to white ]
 [ draw path1 on mask with IN ]
 [ draw path2 on mask with IN ]
 cairo_show_surface_mask (cr, mask);
 
As "fill the intersection of the two paths" is not easy inside of Cairo.
Because the we could just have easily drawn text, an image, a gradient
onto the temporary surface after drawing the two paths.

[ Note cairo_show_surface_mask() doesn't currently exist, so the
  sequence would be even more convoluted ]

> >  - As much as I hate to recommend anybody getting code written to 
> >    spend time on IRC, real time communication is frequently the best 
> >    way to get an issue resolved. irc.freenode.net:#cairo.
> > 
> If I'm not able to convince anyone on mail - where I can rethink
> arguments (mine as well as yours) - I seriously doubt I would be
> able to so on IRC.

Well, the advantage of IRC is frequently that one has a conversation,
not an argument :-)

> > Guessing what you meant for the Win32 backend (did an attachment 
> > go astray?)
> > 
> Just lookin in the patch would help. Here is the relevant part:

Where would I have looked at this patch? It wasn't attached to your
email, it wasn't even part of the big patch you linked to. 
[ looks in bugzilla ] Not in bugzilla either.

>    FAIL2:
> -    if (glyphs)
> -	free (glyphs);
>       if (dx)
>   	free (dx);

That leaks compared to the fix I put in ... glyph_indices is a locally
allocated array that needs to be freed

> @@ -596,7 +594,7 @@
>    FAIL1:
>       free (utf16);
> 
> -   return CAIRO_STATUS_SUCCESS;
> +   return status;
>   }

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.

> > 2005-02-06  Owen Taylor  <otaylor at redhat.com>
> > 
> >         * src/cairo_win32_font.c (_cairo_win32_font_text_to_glyphs): Free
> >         glyph_indices, not glyphs. (Reported by Hans Breuer.)
> > 
> > In terms of your big patch ... I don't see any point in having two
> > win32 backends for Cairo. I think we have to just figure out a plan
> > for how to evolve the single win32 backend to do what everybody needs
> > and merge the relevant parts of your code into that.
> > 
> 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. 

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/20050206/ac46b400/attachment.pgp