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

[Mcirvin, Mathew]

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
   devices.

   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
   inadvisable?

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


Any thoughts would be appreciated...

Matt McIrvin
SavaJe Technologies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/cairo/attachments/20060531/8fc11036/attachment.html