[cairo] Cairo in an embedded environment: removing fontconfig,
16-bit RGB, porting issues
mmcirvin at savaje.com
Wed May 31 11:03:01 PDT 2006
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.
However, we have to modify it in several ways to get it to work
in our environment. Presumably some of these changes aren't of
interest to the general community, but others may be potentially
useful patches to roll back into the distro.
So I have a lot of questions related to this, and was wondering
what people thought:
1. We already use FreeType, but we don't use fontconfig, and we don't
have the kind of complex file-based font system for which it would
be appropriate; nor do we want the extra code footprint associated
with fontconfig. Therefore, we're going to have to strip down the
FreeType font backend to take out those dependencies.
Ned Konz of Squeak seems to have discussed something similar on the
mailing list a couple of years ago. I'm at a very early stage
messing with this, but my initial feelings about this are similar
to his: we already have our own mechanisms for font selection, so
we probably don't need fontconfig's. The only place where the
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?
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. I'm
guessing that other people working in an embedded space may be
interested in this, since it is a common color format on small
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?
3. Our OS is not POSIX-compliant, though it has some similarities. We
also have a different build system that won't easily incorporate
the existing Cairo build process. This means many small changes to
header includes and #defines throughout Cairo and pixman, which may
be difficult and/or undesirable to roll back into the distribution.
So I'm assuming the Cairo project proper doesn't want this stuff.
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
(How about pixman--is that a separate active project or is it under
the aegis of Cairo now?)
Any thoughts would be appreciated...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo