Created attachment 37749 [details]
Misaligned gradient

I created a rectangle that spans the entire A4 page and added extra stops near the endpoint. Here the misalignment is clearly visible. The two ellipses and explanatory text were added separately.

Created attachment 37750 [details]
Interesting artifacts

This screenshot shows artifacts that are the result of the gradient being placed differently depending on the tile which is currently being rendered. At this window size, the tiles are narrow vertical stripes.

Created attachment 37751 [details]
Aliased edge

When two stops coincide (which is frequently used in SVG to create sharp transitions), the edge between their colors is aliased.

Gradient aliasing is expected, as no supersampling is done in pixman (yet).
Test cases (linking just to cairo, if possible) or details of the conditions reproducing the other two problems would be appreciated

Created attachment 37766 [details]
misalignment test case

Minimal test case. Compile with
gcc gradient.c -o gradient `pkg-config --cflags --libs cairo`
Run and look at the gradient.png file.

Created attachment 37767 [details]
misalignment test case output

Output of the test case with Cairo 1.9.15. The red dots mark the position of gradient stops. In the top right corner, the rendering is fairly correct, though the lower dot is not exactly on the line that marks the 100% black boundary. In the bottom left corner, the rendered gradient is completely misaligned with its stops.

Two pixman branches fixing the rendering of linear gradients are available here:
http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/linear-fixed
http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/linear-float

Can you confirm that both fix your rendering issues?
If both work fine, I'm going to investigate their performance.

(In reply to comment #7)
> Two pixman branches fixing the rendering of linear gradients are available
> here:
> http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/linear-fixed
> http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/linear-float

Both branches work correctly on the test case and in the Cairo port of Inkscape.

When the gradient has a transformation matrix with entries that exceed the range of 16.16 fixed point, the rendering is still wrong. That's a different problem though, so I'll file it separately.

(In reply to comment #8)
> (In reply to comment #7)
> > Two pixman branches fixing the rendering of linear gradients are available
> > here:
> > http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/linear-fixed
> > http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/linear-float
> 
> Both branches work correctly on the test case and in the Cairo port of
> Inkscape.

A set of changes based on those branch has recently been merged in pixman/master:

commit 1d4f2d71facd5f2bbce74fbe3407ccea6cf4bea1
Author: Andrea Canciani <ranma42@gmail.com>
Date:   Wed Aug 11 09:58:05 2010 +0200

    Improve precision of linear gradients
    
    Integer division (without keeping the remainder) can discard a lot
    of information. Doing the division maths in floating point (and
    paying attention to error propagation) allows to greatly improve
    the precision of linear gradients.

and

commit 9b72fd1b857494ea928795c89a4f827e56fe26d3
Author: Andrea Canciani <ranma42@gmail.com>
Date:   Mon Oct 18 22:21:52 2010 +0200

    Make classification consistent with rasterization
    
    Use the same computations to classify the gradient and to
    rasterize it.
    This improves the correctness of the classification by
    avoiding integer division.


> 
> When the gradient has a transformation matrix with entries that exceed the
> range of 16.16 fixed point, the rendering is still wrong. That's a different
> problem though, so I'll file it separately.

I can't find the bugreport. It would be very useful to also have a testcase and to also check if the same problem affects radial gradients.