[cairo] Cairo in an embedded environment: removing fontconfig, 16-bit RGB, porting issues

[Carl Worth]

On Wed, 31 May 2006 14:03:01 -0400, "Mcirvin, Mathew" wrote:
> I'm investigating using Cairo to provide rich 2D vector graphics
> capabilities for our embedded OS for small devices.  It does what we
> need and so far seems to be fantastically easy to use.

I'm very glad to hear it's working for you so far.

> 1. We already use FreeType, but we don't use fontconfig
...
>    Cairo backend actually seems to *use* fontconfig's functionality is
>    under the toy text API, which is not necessarily of use to us.
> 
>    Might it be a good idea to try to disentangle the fontconfig-based
>    font selection/presentation stuff from the rest of the FreeType
>    backend?  Are there known pitfalls associated with this approach?

I think it would be fine to add a configure option such as:

	--disable-toy-text

or perhaps:

	--without-fontconfig

or whatever, that would allow cairo to be built without any dependency
on fontconfig. This would remove cairo_select_font_face from the API
at least. Anything else?

> 2. We're using cairo-image-surface.c for a surface backend.  While we
>    use several image formats internally, the native screen pixel
>    format on our platform tends to be 16-bit r5g6r5.
> 
>    Since pixman supports it, exposing it in Cairo is easy.

Yes. In cairo we started with an extremely minimal set of advertised
formats and the plan has been to add other formats according to
demand. So now that there is some demand...

>    It does bring up a naming question.  Calling the format
>    CAIRO_FORMAT_RGB16 would work for now, but it's far from the only
>    16-bit format in use out there; x1r5g5b5 is also common, for
>    instance, and we may well need to support it in the future.  I'm
>    tentatively calling our format CAIRO_FORMAT_RGB565.  Should Cairo
>    go to some more expansive naming convention for color formats?

How about CAIRO_FORMAT_R5G6B5 ?

>    However, there are some changes that might make ports like this one
>    easier to do in the future (and make it easier for us to integrate
>    new Cairo versions), such as centralizing the POSIX header includes
>    under cairoint.h.  That seems to be mostly already done in Cairo
>    proper (not so much in pixman) but there are exceptions, such as
>    several Cairo source files that directly include stdlib.h.  Is
>    there a reason for this?  Would changes to such things be
>    appreciated, or are there cross-platform build issues that make it
>    inadvisable?

That looks like a perfectly reasonable thing to do. There's no real
reason for the includes to be scattered about.

>    (How about pixman--is that a separate active project or is it under
>    the aegis of Cairo now?)

It's definitely a part of cairo now. There are plans underway to
rewrite it significantly this summer, as part of cairo.

It may be that in the future the X server starts relying on this code
as well, and when that happens we can address any necessary separation
of pixman from cairo.

> Any thoughts would be appreciated...

I hope that helps answer some of your questions.

I'm looking forward to your contributions.

-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/20060531/0a6d91dc/attachment.pgp