[cairo] Cairo and GdiPlus or two win32 backends

[Hans Breuer]

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

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

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

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

>>And more general:
>>
>>- How does one provide patches accepted ? [Or is it just a matter of
>>   getting CVS access and simply commit at will? ;]
> 
> 
> My thoughts:
> 
>  - Basic agreement on project goals helps.
> 
While you are concentrating on pixel correctness I was looking more
at high quality print output. To me both seem to fit well with the
projects goals. And both our approaches have defencies in regard
to the top priority of the other approach.

>  - Small patches are easier to get in than big patches
>  
Sure, but that's what I started with. The longer patches are rejected
usually the more they need to grow ;-)

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

> In the end, getting commit access isn't hard. Carl is much more
> flexible and easier to work with than I am in my experience :-)
> 
> 
>>2005-01-15  Hans Breuer  <hans at breuer.org>
>>
>>	* src/cairo_ft_font.c src/cairo_win32_font.c : (text_to_glyphs) don't
>>	free *glyphs to be returned
> 
> 
> Thanks ... I fixed the FT backend problem earlier today. (Both bugs
> crept in because was only testing with Pango and that doesn't use
> text_to_glyphs.)
> 
> 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:

diff --exclude-from=c:\util\tool\diff.ign -u --recursive 
--unidirectional-new-file from-cvs/cairo/cairo/src/cairo_win32_font.c 
my-gtk/cairo/cairo/src/cairo_win32_font.c
--- from-cvs/cairo/cairo/src/cairo_win32_font.c	Fri Feb 04 08:52:13 2005
+++ my-gtk/cairo/cairo/src/cairo_win32_font.c	Sat Feb 05 18:07:15 2005
@@ -586,8 +586,6 @@
      }

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

@@ -596,7 +594,7 @@
   FAIL1:
      free (utf16);

-   return CAIRO_STATUS_SUCCESS;
+   return status;
  }

  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)

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

Thanks,
	Hans

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