[cairo] Operator optimization based on source or dest opacity

[Antoine Azar]

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