Re: Cairo and ISO C++

2014/1/1 Herb Sutter <[email protected]>:
>> During cairo's development, there were some decisions made that we
>> regretted later on.  I was going to suggest that those be revisited for
>> standardization, but reading the documents you linked, I think that will go
>> down the same design-by-committee path that you are trying to avoid.
>
> It sounds like those would be good to know about regardless, if you could share.
>
> Actually we mainly want to avoid that for the initial proposal, but if there are known 'errata' that would be good to know about. Possibly they could be addressed in the C++ wrapping, if they can be addressed without changing Cairo. Alternatively, perhaps this would be a good point to consider addressing some of them in Cairo as well if you think that's proper, given that if this standardization process bears fruit the audience of the Cairo API will expand to a lot of new users. In any event I think it would be good to know about them.

Some notes from a lowly user's perspective (Inkscape developer) - here
are the shortcomings which I encountered while porting the Inkscape
vector graphics editor to use Cairo for all rendering.

1. If you want to add a new backend, you have to do this in Cairo
itself, since the backend API is private. I understand the reasoning
behind this, but in a graphics application such as Inkscape, where we
would like to use Cairo calls as a convenient "intermediate graphics
language" when saving to different formats, this restriction is rather
painful. In order to implement saving to Windows metafiles using the
same code path that renders PDFs, we would need an extra layer of
abstraction between Inkscape and Cairo. Providing a public user
backend API, possibly implemented separately from the internal
backends so that API stability concerns are less of an issue, would go
a long way toward addressing that.

2. Cairo has a very limited concept of graphics state. It is not
possible, for example, to store several paths in a context and switch
between them before paint operations. As I understand, this limits the
implementation options for backends such as OpenGL, which in effect
need to resubmit the path to a GPU every time anything is changed. As
a result, interactive operations such as translation and zooming,
which normally could be implemented simply as a modification of the
OpenGL world-to-screen matrix, are suboptimal. (I know very little
OpenGL, so please correct me if this is not the case, or this issue
does not in fact affect performance.)

3. Although the Pixman library, used to implemented the "image
backend" (aka in-memory software rasterization) in Cairo, supports
almost every pixel format imaginable, this does not carry over to
Cairo. As a result, interfacing with other libraries, such as libpng
and gdk-pixbuf, requires extra conversions. It's not entirely clear to
me why only one 32-bit pixel format is available in Cairo.

4. It would be useful to have some kind of color space support, to
produce color-managed PDFs and potentially to support subset PDF
formats such as PDF/X or PDF/A. This was discussed some time ago on
this mailing list.

Regards, Krzysztof Kosinski
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo