Andrea Canciani <ranm...@gmail.com> writes: > I updated the documentation of radial gradients in my wip/radial branch > (http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/radial) to reflect > my changes (which make pixman gradients behave as specified by pdf > reference manual).
It's of course important to point out here that changing the radial gradients to behave as specified in the PDF spec, really is a change from they used to do. As I understand it, for most common cases, the output is identical to what it used be, is that correct? It would be helpful to have a description of the cases where the behavior differs. Other than that, I'm in favor of just using the PDF spec here. I don't think there is much real value in coming up with our own specification. Regarding this: When a point does not belong to any of the circles, it is transparent. It's probably worthwhile to say explicitly that the point has the RGBA value (0, 0, 0, 0) instead of transparent. That way it's clear that you can't leave out the point when using the SOURCE operator for example. I'm not completely clear on what cairo is doing (or supposed to do) in this case. The cairo SOURCE operator is bounded by the mask, but is it also bounded by the source? > The code is not yet ready to be merged (it uses __int128 variables, which > probably won't work on 32 bit architectures), but I would appreciate reviews > (expecially of the new documentation) and testing. If __int128 is intended to help with non-FPU systems, then let me repeat that using floating point in pixman is totally fine, and almost certainly faster than any __int128 would be. Soren _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman