[Pixman] [PATCH 3/3] BILINEAR->NEAREST filter optimization for simple rotation and translation

Andrea Canciani ranma42 at gmail.com
Mon May 23 07:41:16 PDT 2011


On Mon, May 23, 2011 at 3:16 PM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Mon, May 23, 2011 at 9:48 AM, Andrea Canciani <ranma42 at gmail.com> wrote:
>> On Mon, May 23, 2011 at 8:43 AM, Andrea Canciani <ranma42 at gmail.com> wrote:
>>> On Sun, May 22, 2011 at 11:15 PM, Siarhei Siamashka
>>> <siarhei.siamashka at gmail.com> wrote:
>>>> From: Siarhei Siamashka <siarhei.siamashka at nokia.com>
>>>>
>>>> Simple rotation and translation are the additional cases when BILINEAR
>>>> filter can be safely reduced to NEAREST.
>>>
>>> I believe that this reduction is valid for any matrix which describes
>>> a unit transform followed
>>> by an integer translation (i.e. rotation(90 degrees), scale(-1,1),
>>> translate(1,0) composed
>>> in any possible way).
>>>
>>> This happens whenever the translational component of the matrix is
>>> integral, the projective
>>> component is identity (already tested by AFFINE_TRANSFORM) and the
>>> upper-left 2x2
>>> matrix multiplied by its transpose results in the 2x2 identity.
>>
>> Uh, we already have an implementation of this (which is what cairo
>> uses to optimize filters to nearest):
>> http://cgit.freedesktop.org/cairo/tree/src/cairo-matrix.c#n728
>> (lines 728-762)
>
> Yes, I know that cairo has such optimizations, you mentioned them earlier :)

I wanted to point to an existing (hence at least somewhat tested and
working) implementation of that reduction.

>
> I intentionally tried to keep the initial patch simple, lightweight
> and deal only with the identity transform because this is the most
> important case. The last patch in the series attempts to extend
> bilinear->nearest reduction to handle a bit more cases (check for the
> already set ROTATE flags is really cheap), but looks like not
> everything is so smooth (the FIXME part), which which needs some extra
> investigation.

A similar "magic" number came up in cairo tests:
http://cgit.freedesktop.org/cairo/tree/test/large-source-roi.c#n52

It looks like some checks against overflow conditions are too restrictive.

>
> Now we are going to basically have duplicated functionality in cairo
> and pixman, but pixman needs this optimization for the applications
> which use XRender directly or bypass cairo in some other way.

Yes, we already talked about this and if there are apps whose performance
can be enhanced by simplifying filtering in pixman (i.e. they do not rely on
cairo or something elso to do the reduction), then it is something appropriate
(and easy) to do in pixman.

Andrea


More information about the Pixman mailing list