C Assembly C++ M4 Makefile Perl
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
contrib ci: Add .gitlab-ci.yml Jun 5, 2018
demos Revert "demos/scale: Added pulldown to choose PIXMAN_FILTER_* value" Sep 3, 2016
pixman vmx: Fix vector loads on ppc64le May 14, 2018
test test: Fix stride calculation in stress-test Jul 6, 2018
.gitignore test: Added more demos and tests to .gitignore file May 5, 2015
.gitlab-ci.yml ci: Add .gitlab-ci.yml Jun 5, 2018
AUTHORS Add the files. May 4, 2007
CODING_STYLE CODING_STYLE: Delete the stuff about trailing spaces Aug 4, 2010
COPYING COPYING: added Nokia to the list of copyright holders Dec 17, 2010
ChangeLog Add the files. May 4, 2007
INSTALL Change autogen.sh to call autoreconf. Remove reference to libcomp.h May 4, 2007
Makefile.am Change default GPGKEY to 3892336E, which is soren.sandmann@gmail.com Jan 29, 2013
Makefile.win32 build: Improve win32 build system Sep 15, 2012
Makefile.win32.common build: Use `del` instead of `rm` on `cmd.exe` shells Dec 23, 2015
NEWS Add the files. May 4, 2007
README README: Add guidelines on how to contribute patches Jan 23, 2013
RELEASING RELEASING: Add note about changing the topic of the #cairo IRC channel Aug 7, 2013
autogen.sh autogen.sh: Support GNOME Build API Jan 5, 2012
configure.ac pixman-image: Added enable-gnuplot config to view filters in gnuplot Sep 2, 2016
pixman-1-uninstalled.pc.in Fix pixman-1-uninstalled.pc to point to the libtool library Dec 20, 2008
pixman-1.pc.in build: Remove useless DEP_CFLAGS/DEP_LIBS variables Sep 16, 2012


Pixman is a library that provides low-level pixel manipulation
features such as image compositing and trapezoid rasterization.

Questions, bug reports and patches should be directed to the pixman
mailing list:


You can also file bugs at


For real time discussions about pixman, feel free to join the IRC
channels #cairo and #xorg-devel on the FreeNode IRC network.


In order to contribute to pixman, you will need a working knowledge of
the git version control system. For a quick getting started guide,
there is the "Everyday Git With 20 Commands Or So guide"


from the Git homepage. For more in depth git documentation, see the
resources on the Git community documentation page:


Pixman uses the infrastructure from the freedesktop.org umbrella
project. For instructions about how to use the git service on
freedesktop.org, see:


The Pixman master repository can be found at:


and browsed on the web here:


Sending patches

The general workflow for sending patches is to first make sure that
git can send mail on your system. Then, 

 - create a branch off of master in your local git repository

 - make your changes as one or more commits

 - use the 

        git send-email

   command to send the patch series to pixman@lists.freedesktop.org.

In order for your patches to be accepted, please consider the
following guidelines:

 - This link:


   describes how what a good patch series is, and to create one with

 - At each point in the series, pixman should compile and the test
   suite should pass.

   The exception here is if you are changing the test suite to
   demonstrate a bug. In this case, make one commit that makes the
   test suite fail due to the bug, and then another commit that fixes
   the bug.

   You can run the test suite with 

        make check

   It will take around two minutes to run on a modern PC.

 - Follow the coding style described in the CODING_STYLE file

 - For bug fixes, include an update to the test suite to make sure
   the bug doesn't reappear.

 - For new features, add tests of the feature to the test
   suite. Also, add a program demonstrating the new feature to the
   demos/ directory.

 - Write descriptive commit messages. Useful information to include:
        - Benchmark results, before and after
	- Description of the bug that was fixed
	- Detailed rationale for any new API
	- Alternative approaches that were rejected (and why they
          don't work)
	- If review comments were incorporated, a brief version
          history describing what those changes were.

 - For big patch series, send an introductory email with an overall
   description of the patch series, including benchmarks and
   motivation. Each commit message should still be descriptive and
   include enough information to understand why this particular commit
   was necessary.

Pixman has high standards for code quality and so almost everybody
should expect to have the first versions of their patches rejected.

If you think that the reviewers are wrong about something, or that the
guidelines above are wrong, feel free to discuss the issue on the
list. The purpose of the guidelines and code review is to ensure high
code quality; it is not an exercise in compliance.