[cairo] Cairo and GdiPlus or two win32 backends

[Carl Worth]

On Sat, 05 Feb 2005 20:26:27 +0100, Hans Breuer wrote:
> So if noone feels qualified to review new backend code that new
> backend will simply never be accepted in Cairo ?

The goal is to always have an active maintainer for any code in the
tree. If new code comes along and none of the current maintainers are
prepared to adopt it, then that code will need a new maintainer to
come along with it.

There's an important difference between, "Here's some code I'd like
you to take", and "Here, I'd like to maintain this code within the
cairo tree", particularly in terms of long-term responsibility. I'd
been interpreting your offer of a win32 backend in terms of the
former, but if you had actually meant the latter, (you've certainly
been updating things regularly), please let me know.

> Another attempt for a short summary :

Thanks. This looks quite helpful to the discussion:

> 
>                        Maarten       Stuart       Hans           Owen
> exported symbols by:  #pragma      #pragma    libcairo.def       ?(1)
> compiler used:         msvc?        msvc         msvc           mingw
> language:                C           C++          C              C

These first three elements seems like implementation details, and as
such, are secondary issues, (whereas getting the public API right, and
correct visual results, are primary issues).

> font backend:        freetype    unfinished    freetype        win32?base 

This is an important criteria and a compelling argument for Owen's
code, currently in CVS. An important goal of the design of the font
API is to allow native font backends on various platforms. And the
native win32 font backend was definitely one aspect of that argument.

> based on (backend):    image        GDI+       Windows          Cairo
>                                                 Metafile        Metafile?

My understanding of Owen's implementation is that is uses GDI. Looking
at the implementation, I see things like BitBlt, AlphaBlend, and
CreateSolidBrush (hurray for clean namespaces!). But, as before, this
is just implementation detail and it's easy to change things to use
something else.

> target:                HWND          HDC       multiple(2)    DIB/HDC?(3)

Now, this looks like something that does have some significant impact
on the user-level API. And it's also the kind of thing I meant when I
said I'm not qualified to review Win32 code. I don't know anything
about how to determine if an interface based on HWND is better than an
interface based on HDC. That's the kind of thing I'd rather let a
win32 maintainer deal with.

But, let's take a look at the two proposed interfaces, (ignoring the
extra font stuff, and looking just at "set_target" since
"surface_create" accepts the same arguments).

 Here's what's in CVS:

	void
	cairo_set_target_win32 (cairo_t *cr,
	                        HDC      hdc);

and here's what in your patch:

	typedef enum
	{
	    CAIRO_WIN32_DIRECT_HDC, /* the backend from above */
	    CAIRO_WIN32_TARGET_HWND,
	    CAIRO_WIN32_TARGET_CLIPBOARD,
	    CAIRO_WIN32_TARGET_WMF,
	    CAIRO_WIN32_TARGET_EMF,
	    CAIRO_WIN32_TARGET_PRINTER
	} cairo_win32_target_t;

	void
	cairo_set_target_win32x (cairo_t             *cr,
	                         const char          *filename,
	                         void*                target,
	                         cairo_win32_target_t type,
	                         int                  width,
	                         int                  height);

This interface raises a few questions in my mind. Are all of those
different target types fundamentally different such that they need to
be in the backend? Is there some smaller set of targets that the
backend could provide and allow the user to send things around?

What's the filename argument for?

Are width/height necessary here? (We've tried to avoid having extra
arguments like these if they are nicely captured in the window system
object. We succeeded in glitz. I don't know where we stand with Quartz
(which has width/height). We failed in Xlib, where I didn't include
them originally, but I need to put them there now to avoid a roundtrip
to the server).

I don't like the void* style for the public interface. That's a big
piece of type-un-safety at the primary entry point for the backend. If
we do want to provide multiple sub-types of surface within a backend,
then I think each one deserves its own function name.

> > patch. (Admittedly, I hadn't read either patch. I'm still not
> > qualified to review win32 code).
>
> There should be nothing special to win32 code except some ugliness ;-)

It's more the metafile vs. HDC stuff that I alluded to above. I don't
really know a lot about these win32 interfaces.

I've since gathered that your metafile approach allows a vector-based
backend on win32. I'm not convinced that a vector-based backend is
very workable right now. Or, rather, while it can work, it cannot
provide device-independent output as one might expect from something
producing vectors.

For example, cairo the decomposition of splines into polygons that
cairo performs takes into account the user-specified tolerance value
and the current device coordinate system. As such, transforming the
resulting vector to some other device space can yield the wrong
results.

In this view, cairo is suitable for producing output for direct use,
(eg. display on a screen or for printing at a particular DPI), but not
as useful at creating vector files to be further manipulated.

At times I've wanted something for producing that kind of editable
file, (eg. "print to SVG" with the same interface as cairo). But
something like that would be quite different than what cairo is
today. It would be an entirely different backend interface that would
hook in immediately below the top-level API.

And some people have made convincing arguments that such an interface
would belong outside of cairo anyway. (eg. if you are creating SVG or
PDF files to be edited, then you will likely also want to include lots
of things that don't belong in cairo's interface).

> But how to continue now? As I see it there are still quite some open
> issues even if one ignores the new backend - which is just that,
> and has almost no influence on the rest of Cairo - with backend
> specific headers even less ;-)

Let's hit those issues! (Speaking only for myself here, as usual).

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

Portability patches are usually pretty easy to accept. I grumble a bit
when "foreign" environments make my code ugly, but I usually get over
it.

If there is a separate build system that needs to be maintained,
(ie. something independent from the current Makefile.am stuff), then I
don't know how to avoid it getting second-class citizenship. I'd be
glad to let it live in CVS if someone is interested in keeping it up,
but I wouldn't promise to never break it, (since I couldn't test it,
which basically guarantees I would break it).

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

Should probably be fine. (Though I don't really like the ABI volatility
that C++ implies). I plan to split up cairoint.h which should
alleviate the "operator" problem.

> - Is a vector based backend something considered useless or -
>    if not - will there be better support in the backend interface ?

I think I've covered this above. It's not useless, (see the PDF
backend we have already). But it's not geared for device-independence,
(which is what some people assume when they hear "vector").

>    - Extracting clip masks from bitmaps certainly is possible but
>      shouldn't this info better be provided as vectors?

The current backend rendering model really is a pipeline of
compositing operations with very little geometry to speak of.

>    - If I understood the operators correctly they are a mix between
>      simple drawing mode and some logical operations on objects.

I'm afraid I don't understand this. The compositing operators are all
defined in terms of operations on image channels, not geometric
objects.

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

I'm not an expert on printer interfaces. But I'm quite sure we don't
want cairo trying to become a multi-platform printing system
abstraction system, (compare with old threads on why we decided to
expose multiple font systems). That would be a disaster for sure.

I've been hopeful that print systems will be even easier to deal with
than the font systems have been, since hopefully they won't have to be
mentioned in cairo's interface at all. My goal has been to be able to
promise "cross-platform quality in printing" by letting cairo be
responsible for computing the image to be printed. The user will still
be responsible for hooking up the plumbing to get the image to the
printer.

Should generating a PostScript stream satisfy the needs of printing
systems on most all relevant platforms?

> - How does one provide patches accepted ? [Or is it just a matter of
>    getting CVS access and simply commit at will? ;]

Almost every time I accept more than one patch from somebody, I turn
around and ask that user if they would like CVS access to make things
easier in the future.

> On my local disk there are also small modifications to build libpixman
> and cairo_snippets including dependencies with the M$ toolchain.
> It would be nice if these can be reconsidered ...

Please feel free to send these again if we just missed them.

> Even if you are not interested in win32 stuff at all you may be
> interested in fixing a serious bug in *text_to_glyphs() :
> 
> 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

Stuff like this is definitely worth sending as a separate patch,
(either here on the list or in bugs.freedesktop.org, whichever you
prefer).

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050207/ad5702ca/attachment.pgp