[cairo] Pixman refactoring

Soeren Sandmann sandmann at daimi.au.dk
Tue May 5 01:07:38 PDT 2009


It's no secret that the pixman code is quite messy and
incomprehensible in many ways.

Much of this can be explained by pixman's history: it originated in
the render implementation in XFree86 and since been forked into the
kdrive X server, the Xorg server, and cairo, until the forks were
reunited as the pixman library.

Some of the issues:

- The code for the various image types are sprinkled across many
  files; rather than being structured by object type, it is instead
  structured by functionality, something that was dictated by the X
  server's towers of function wrapping.

- There is 'accessor' code that is compiled twice because the wfb code
  in the X server needs to access pixels through function calls. This
  is achieved with annoying macros used in some, but not all places. 

- The history as both framebuffer and pixman code is showing up in
  coding style.Some names have "pixman" prefixes, some have "fb", and
  some have "Fb". Some names are in camel case, some use underscore
  separators. Some use both. This:

        fetchProc32 ACCESS(pixman_fetchProcForPicture32)

  may be one of the ugliest names ever created. There are multiple
  formatting conventions in use.

- There are large amounts of duplicated code. Some of it is there for
  performance reasons, some is just gratuitous duplication.

One result of this mess is that people are implementing functionality
in cairo that ideally would live in pixman because they are useful for
both X and cairo. Examples include the gradient dithering, the polygon
scan converter, and the drm backend.

So I am going to do some major refactoring of pixman. Along the way I
hope to also make the Render specification much more detailed and get
it to match the implementation and vice versa.


* Make drawable, gradient and solid fill images into objects that know
  how to produce pixels and scanlines for the rest of the
  implementation to use.

* Move all code and tables pertaining to architecture specific fast
  paths into architecture specific files.

* Move all C fast paths into their own file

* Implement the composite() function in one file, rather than two.

* Get the Render spec and pixman to largely agree with each-other

* Reformat with consistent naming and coding style (basically the one
  described in cairo/CODING_STYLE with a few changes).

Some of this is done already, in these branches:



The refactor branch has code to eliminate duplicated code from the
general compositing path. The separate-images branch branches off
refactor and splits gradients solid fills and pixel-based images into
their own files. There is a document in there called 'refactor' which
contains various notes and specification drafts.

I expect to merge the refactor branch to master soon, and the
separate-images branch soon after that. Review and testing (especially
if you use wfb), is appreciated.

Someone is going to ask, so I may as well answer preemptively: I don't
expect any significant performance impact (positive or negative) from
this. The refactored version will do basically the same amount of work
per pixel with the same number of memory references and virtual

The one possible exception to this is that the combiner functions will
now take a mask and do the full (src IN mask) OP dest, rather than it
being done in two step (src IN mask), then (srcmask IN dest). If
anything, this should be slightly faster because it avoids one
intermediate buffer.


More information about the cairo mailing list