[Pixman] 0.18.0 schedule

Soeren Sandmann sandmann at daimi.au.dk
Mon Mar 8 09:23:42 PST 2010

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> This can be solved (at least for the normal SVG radial gradients where the
> focal point is inside outer circle) by for example taking the distance of the
> furthest corner of the area being composited from the outer circle center, and
> dividing it by the distance from the focal point to the outer perimeter. If
> the calculated value is less than 32K, then 16.16 fixed point can be used
> safely. Otherwise 't' may need to be clipped as floating point value before
> converting to integer.

If the right solution is to clip before converting to integer, then we
might as well clip based on the repeat mode, and then the gradient
walker could just take a float instead of a fixed point.

I'd be slightly worried about the performance implications of that,
but pixman probably needs to use more floating point internally in any
case. See


for example.

> Probably normal people will never use radial gradients with the extreme corner
> case parameters, the image just does not look right anyway, so it can't be
> distorted any worse by additional checks.
> By the way, technically gradients are performing point sampling. And it may
> produce bad image quality and rough edges on the transition between stops.

Yes, and REPEAT_NONE gradients have aliasing at the edges. Image
downscaling has essentially the same problem. See these mails:



The proposal there is to add a new resampling feature that would be
used for both gradients and images. You'd be able to say something

        pixman_image_set_resampling (image, filter, rate_x, rate_y);

where rate_x and rate_y are given in sample points per destination
pixel, and filter would be a symbolic value like BOX or GAUSSIAN or

It probably also makes sense to add dithering, certainly for 16 bit
gradients, but even 24 bit gradients can show banding in some cases.


More information about the Pixman mailing list