[cairo] Cairo and GdiPlus or two win32 backends

[Hans Breuer]

On 07.02.2005 18:05, Carl Worth wrote:
> 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.
> 
Sounds reasonable.

> 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.
> 
I'm prepared to maintain the win32 specific build files.
For really maintaining or writing I'd probably need to understand
the Cairo rendering model more, some documenation of the operators
effect or knowm defects of backends would certainly help ;-)

> 
>>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).
> 
At least when some backend in cvs does not build without modifications
of other code the choice of programming language looks like a primary
issue to me. But now that GDI+ should not be used anymore I agree it
became a secondary issue.
> 
>>font backend:        freetype    unfinished    freetype        win32?base 
> 
> 
> This is an important criteria and a compelling argument for Owen's
> code, currently in CVS.
In fact both win32 backends should work with both font backends at the
moment. But also they both don't implement surface_show_glyphs(), i.e. 
bitmapped glyphs.

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
Both backends use GDI the "Graphics Device Interface" which allows
vectors and bitmaps. From my understanding GDI+ is just a conglomerate
of stuff useful for browser implementation on top of GDI (In fact there
are two GDI, the 16 bit version of win9x, highly limited, and the much
more capable version of winNT/2K/XP.
Dixect(X/3D/etc) is another graphics interface design to be faster but
AFAIK too limited to e.g. build a 'cooperative' widget toolkit on top
of it (mainly useful for games and 3D, an attempt to replace OpenGL)
And sometimes in the future there will be Avalon ;-)

> at the implementation, I see things like BitBlt, AlphaBlend, and
> CreateSolidBrush (hurray for clean namespaces!). 
Yeah, that the reason why I don't like to include <windows.h> in *any*
libary header. Having written a wmf plug-in for Dia and also done
Dia's Windows Printing interface
>But, as before, this
> is just implementation detail and it's easy to change things to use
> something else.
>
I don't think so but we'll see.

> 
>>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. 
IMO the two public api functions (set_ and create_surface) can and
should be considered experimental for a new backend, no need to
freeze too early.

> 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.
> 
If the maintainer is going to actually integrate Cairo in some higher
level module/application fine with me. If the api requires a major
rewrite/redesign on the level above I'm not sure ;-) See
http://mail.gnome.org/archives/gtk-devel-list/2005-February/msg00029.html
for my problems with the proposed 'small' interface.
> 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?
> 
Every target requires some special handling in the backend, e.g.
printer : map create/destroy to StartDoc, EndDoc; map show_page
	to StartPage/EndPage
wmf, emf : specific conversion from the internal metafile to
	a file format (emf is the 'enhanced metafile', wmf the
	'legacy' metafile format
clipboard : show_page() puts the metafile into the systems clipboard

The latter three could probably be done in user code with an api
exposing the metafile HANDLE. But I don't see any benefit in
polluting api user code with such. Also most of these conversions
need to be triggered by Cairo's rendering api.

> What's the filename argument for?
> 
There are two (to three) targets actually being able to produce
file output. WMF and EMF als well as 'print to file'. Maybe I'll
add BMP later.
> Are width/height necessary here? 
I'm not sure. At the moment it isn't used anywhere but may
become handy. Again I don't think the API should not be frozen
too early.
> (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.
> 
I don't like libraries including *any* system headers, especially not
<windows.h>. And not only for namespace problems. But it's a matter
of taste where I think consistency across a whole libraries interface
is more importatnt than personal prefernces ;-)
> 
>>>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.
> 
A HDC is a HANDLE to a device context (which can be created to access
a printer page, a window a bitmap etc.)
A windows metafile is basically a stream of GDI API calls with their
parameters. The system provides service to play metafiles convert them
or exchange via clipboard. It's one more indirection than the HDC.

> 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.
>
The metafile does not need to be pure vectors it can interleave bitmaps,
glyphs and vectors at will (also selecting of fonts). Almost any GDI
api call can be recorded in a windows metafile. My newest version
does use AlphaBlend() and BitBlt() was there already.
One more nefit I see with the windows metafile approach is the
possibility to pass through bitmaps with their native resolution,
which may be (or usually is?) smaller than the DPIs used for
output.

> 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.
> 
Yeah, seen this, but don't you have a similar effect with resampling
bitmaps (e.g. PNG backend)?
Also the backend returned DPIs have a much bigger impact on the
metafile size than usually required for a vector format.

> 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).
>
What I do care more about is bandwith. To me the actual size of a PDF
produced is also part of the quality. To some extent I think this holds
true for interfacing printers as well. Under this light I consider the
current Postscript approach as near useless.

> 
>>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).
> 
Fine with me. IMO this can almost completely be resolved by giving
a heads up early enough before a new release/snapshot.

>>- 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").
> 
Windows Metafiles don't have (even near) infinite resolution anyway
so at least I would not expect device-independence.

> 
>>   - 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.
> 
But there are plans for improvements?
> 
>>   - 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.
> 
Seems to be my misinterpretation of the (wrong/incositent?) output
of the PNG backend.

> 
>>- (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. 
At least page sizes need to come in somewhere or some way to produce
pagination.

> 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?
> 
If win32 support is really wanted PostScript is definitely not enough.
And neither is PDF. In the history of Dia evolving on win32 there first
was PostScript to file, than PostScript file to PostScript only printers.
Later the wmf plug-in was extended a little bit to have native printer
access which for many people seems to be the only acceptable way.

	Hans

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