A list of pixman projects in need of volunteers.
first are well-understood and just need somebody to do them; projects
listed towards the end are not as well understood and may need
research and experimentation.
Code Cleanups / Janitorial The pixman source is messy in some
places. Some examples:
- There is confusion about what data type is used for gradient coordinates
- Some of the fast path implementations have too much duplicated code that could be generated with C macros instead
- The 'fast path' tables are not really necessarily fast paths anymore, so they probably should be renamed to 'composite_functions'.
- The configure.ac file overwrites the CFLAGS variable. It shouldn't do that because CFLAGS may be set by the user.
Regression Test Suite
The scaling-test, blitters-test, and composite-test programs cover
large parts of the compositing routines, but they have no provisions
for regression testing, that is, testing that a specific bug that was
fixed at one point in time does not appear again.
Use Transformations with more range and precision Internally
The current fixed-point transformations do not have sufficient range
in many cases. Part of this project is finding out how to let the test
suites cope with minor differences in the output.
Improve the X Server's Use of Pixman
Make the X server keep pixman_images around instead of creating and
destroying them on every rendering request. This is mainly an X server
project, but changes to pixman may be required.
Optimizations of all parts of the code are welcome. Possibilities
include, but are not limited to:
- More CPU specific fast paths
- Add architecture specific iterators for gradients and sampled
Tiled access pattern. The scanline based access pattern is not
optimal for a number of operations, such a rotations,
transformations and filters. Compositing on a tile-by-tile basis
instead of on a scanline-by-scanline basis would have better cache
Reduce memory use by using a more compact layout for pixman
images. Fields that are really booleans could be packed together
using bitfields or bitmasks.
Certain operations can be reduced from OVER to SRC if we detect that
the parts of a source image that are within the clip region are
Move Core X Rendering Code Into Pixman
Move the remaining software rendering code for things like XCopyArea
and XDrawLines from the X server into pixman.
Support for Bounded Operators
The compositing operators in pixman and XRender are unbounded
in the sense that the mask is not always delimiting the effect of the
compositing operation. That makes them a poor match for many of
It may make sense to add versions of the pixman operators that
are bounded, ie., use the equation:
(source OP destination) LERPmask destination
rather than the current equation:
(source IN mask) OP destination
Support for Subimages
Subimages allow the user to construct pixman images that reference a
rectangle of another image. This feature is necessary to get correct
support for rendering to windows in X.
The difficult part of subimages is that when the pixels are
narrower than a single byte, subimages may start in the middle of a
byte. Some slightly gory reorganisation of pixman internals may be
Other testing ideas
- Make it such that the output of implementations can be tested
against each other.
- Add a slow 'reference' implementation that uses double precision for all computations. This can then be used to relax the current bit exact testing.
- Look into comparing output using a perceptual metric instead of the current bit exact metric.
Higher Quality Image Filtering
Add better filtering, especially for downscaling transformations.
Higher-Precision and -Range Formats
It is desirable to support floating point channels, both 16 and 32
bit. This requires evaluating the compositing operators and finding
out how what they mean when color channels are not confined to the [0,
A polygon image type will allow rasterization and compositing to
happen in one pass. Among other things, this will eliminate3 the need
to zero-fill large temporary masks.
Support for Compositing Spans
The current version of cairo is representing polygons internally
as a list of spans. It may make sense to add support for this data
structure directly to pixman (and then to XRender).
Find out how to make pixman do multithreaded rendering.
A relatively simple subproject of this is to simply add threading
primitives such as atomic ops and mutexes. These can then be used to
implement a simple image cache to cut down on the time spent in
Add the ability to do more complicated "expressions" of
compositing. For example, you would be able to ask pixman to do:
((x IN y) OVER z) ADD ((w OVER a) ATOP b)
in one pass.
Make an OpenGL backend
This may require new API.
Make it a DRM Client
Enable pixman to render to drm buffer objects.
Dynamically generate machine (and possibly shader) code to improve
both performance and maintainability.
Color Management / Gamma Correction
Find out what color management support is needed in cairo, XRender,