[Pixman] Compute flags at validation time instea

[Soeren Sandmann]

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

> Looks good in general.
> 
> Except that the introduction of FAST_PATH_IS_OPAQUE flag may probably make
> operators optimization a bit more tricky for PIXMAN_REPEAT_NONE
> case.

One possibility might be to just introduce another flag, something
like FAST_PATH_OPAQUE_SAMPLES, that would indicate whether the
sampling grid has any alpha. It would be set regardless of repeat mode
as long as there weren't other sources of transparency.

The real IS_OPAQUE flag could then be computed in do_composite() based
on an improved version of image_covers() that would also deal with
transformations.

Or maybe all the checking for REPEAT_NONE should just happen in
do_composite() and the opaque flag should just refer to the sampling
grid.

> Also "Restructure the code to use switches instead of ifs" part probably may
> have uncertain effect on performance. Optimization manuals say that ifs are
> generally faster than switches when one of the cases has much higher
> probability than the others.

Note though that the switches replaced constructions with more tests
in them. For example, this:

    if (image->common.filter != PIXMAN_FILTER_CONVOLUTION)
    {
       flags |= FAST_PATH_NO_CONVOLUTION_FILTER;

       if (image->common.filter == PIXMAN_FILTER_NEAREST)
           flags |= FAST_PATH_NEAREST_FILTER;
     }

had two tests and two updates of flags, where the new code:

    switch (image->common.filter)
    {
    case PIXMAN_FILTER_NEAREST:
    case PIXMAN_FILTER_FAST:
        flags |= (FAST_PATH_NEAREST_FILTER | FAST_PATH_NO_CONVOLUTION_FILTER);
        break;

    case PIXMAN_FILTER_CONVOLUTION:
        break;

    default:
        flags |= FAST_PATH_NO_CONVOLUTION_FILTER;
        break;
    }

has only one test and only updates the flag once. 

I tend to think that time spent worrying about such details would be
better spent looking at profiles. You just get a whole lot more bang
for the buck doing that.


Thanks for the comments,
Soren