[cairo] Cairo and GdiPlus or two win32 backends

[Owen Taylor]

On Sat, 2005-02-05 at 20:26 +0100, Hans Breuer wrote:

> Another attempt for a short summary :
> 
>                        Maarten       Stuart       Hans           Owen
> exported symbols by:  #pragma      #pragma    libcairo.def       ?(1)
> compiler used:         msvc?        msvc         msvc           mingw
> language:                C           C++          C              C
> font backend:        freetype    unfinished    freetype        win32?base 
> based on (backend):    image        GDI+       Windows          Cairo
>                                                 Metafile        Metafile?
> target:                HWND          HDC       multiple(2)    DIB/HDC?(3)
> 
> (1) my guess is libcairo.def, approach succesfully used from GLib to
>      The GIMP; maybe generated by CPP as recently introduced in GTK+
>      but at the moment it apears to rely on GCC auto export facility

Currently, yes, it is depending on GCC / libtool for exports. There is
no problem adding a .def file, but without a need for it in
my build environment it wasn't a first priority.

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

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.) But for many other parts
of Pango you can't even approximate the right results.

> - Should Cairo be buildable with something other than GCC ?

I'm sure we can add MSC makefiles to the build. It's no more
satisfactory than for GLib/GTK+ ... separate makefiles means 
that many releases will have broken makefiles. But there isn't really a
good alternative for now. (automake is too big of a win to give it
up on other platforms and making libtool handle MSVC is by all 
evidence not easy.)

> - Should it be possible to write Cairo backends in C++ (probably
>    to be resolved by cairo-backend.h separartion) ?

The conclusion we came to was that we'd wait to fix up uses of
'operator' until we actually had a C++ based backend. 

I hope we do get around to splitting up cairoint.h sometime soon,
since it is a beast to find things in, but that's more of
a code maintenance issue.

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

There's nothing sacred about the current frontend/backend interface;
it's been changed to accomodate Glitz, PDF, FreeType fonts, 
my Win32 backend and so forth. It just takes a proposal, and agreement
on the proposal, and a patch.

> - (not really Cairo but it's planned usage) How to cross platform
>    interface printers ?

At least in my opinion, out of scope for Cairo. The way that an
app lets a user select a printer is to show a printer dialog. And
that's GUI toolkit land.

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

 - Small patches are easier to get in than big patches
 
 - 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.

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

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.

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/66cfe22d/attachment.pgp