[cairo] Operator optimization based on source or dest opacity
Antoine Azar
cairo at antoineazar.com
Sat Mar 1 09:47:23 PST 2008
Hey Soren,
>Only if the weights sum to 1, right?
>
>Unfortunately, the render spec doesn't say exactly how convolution
>filters should work, so the best we have to work with is the code. And
>I don't see anything in the code that prevents the user from
>setting, say, all the weights to 0.
Traditionally the result of a convolution filter is divided by the
sum of the kernel. I'm looking at the code in
fbFetchTransformed_Convolution, and we're not doing that division
(we're dividing by 65,536, I suppose that's a factor by which the
weights in filter_params are premultiplied by). If that's really the
desired implementation then you're right, but I don't recall seeing
convolution filters done this way.
>We can't rely on what cairo happens to do or not do. Even if cairo
>were the only user of pixman, that would still be a recipe for
>disaster.
It wouldn't if it was documented properly :-)
>Pixman is (more or less) an implementation of the X Render extension,
>whose specification is here:
>
>
>http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;h=af158b500590a37c0ffe0c0a1a147e489dfd4345;f=renderproto.txt
>
>It is certainly legal to use X Render to composite with images that
>are partially transparent, including where this transparency is the
>result of a transformation.
>
>So we will need to make sure that the image is completely opaque
>before applying this optimization.
>
>The alternative would be to have pixman_image_is_opaque take x, y,
>width, height parameters and make it a check for whether that
>sub-image is opaque. The compositing routine could then first check
>whether all the rectangles were opaque, but I think this would be way
>too complicated for way too little gain.
I understand what you're saying, but I can't help cringing when we
reject real-world performance boosts simply to leave a system
flexible enough to accept bogus input values. Specifying a
rectangular source image with repeat_none and then setting
xSrc/ySrc/width/height values that don't correspond shouldn't be
valid input values in a high-performance rendering/compositing lib.
Otherwise we need to rethink our system because we're executing lots
of useless code.
I can reject any repeat_none/transformed source for this
optimization, but we'll be missing out on a LOT of cases where a user
specifies a rectangular opaque source image, translates it and paints
it over a destination. Actually this is probably the most frequent
case affected, so I'll probably run the xSrc/ySrc/width/height
specified through the transformation matrix to check that we're still
within the source image when verifying for opacity.
Thanks,
Antoine
More information about the cairo
mailing list