Pixman Projects

A list of pixman projects in need of volunteers.

Projects listed 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

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 images.
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 locality.
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 completely opaque.

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 cairo's operators. It may make sense to add versions of the pixman operators that are bounded, ie., use the equation:

(source OP destination) LERP_mask 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 necessary.

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, 1] interval.

Polygon Image.

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

Multithreading

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 malloc().

"Expressions"

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.

JIT Compiler

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, and pixman.