[Pixman] [RFC] Performance reporting capabilities for pixman?

[Siarhei Siamashka]

On Friday 29 October 2010 04:17:28 Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> 
> > As there are no more comments/opinions, I'm going to prepare some more or 
less
> > final patches based on what we have now. They will be posted to the mailing
> > list shortly.
> 
> I noticed this:
> 
> > @@ -745,7 +745,11 @@ pixman_image_composite32 (pixman_op_t      op,
> >      
> >      if ((mask_flags & BOTH) == BOTH)
> >         mask_flags |= FAST_PATH_IS_OPAQUE;
> > -    
> > +
> > +    src->common.flags = src_flags;
> > +    if (mask)
> > +       mask->common.flags = mask_flags;
> > +
> >      /*
> >       * Check if we can replace our operator by a simpler one
> >       * if the src or dest are opaque. The output operator should be
> 
> That can't be correct, because some of the flags are computed on the
> fly. If you store those in the image, then they will survive until
> next time that image is used, when they may no longer apply.

Thanks. That's a good catch. So basically some part of the flags is stored
with the image itself and updated in a lazy way. The other flags are only
valid for the current operation.

This can be solved by introducing a flag mask containing only the flags from
the first group. It could be used to clear the 'scratch' flags from the second
group when reading a value from 'common.flags'.

> I'm not sure how to get the full set of flags passed to the general
> code in a nice way. One hack would be to just store them in global
> variables, but that's rather ugly.
> 
> Another possibility might be to resurrect the idea of a
> composite_args_t struct containing the arguments that are currently
> passed to pixman_composite_func_t. That would make it cheap to pass
> the full set of flags. That's a large patch though, and still somewhat
> ugly. It also has unknown performance implications.

Yes, I would prefer a non-intrusive and/or zero overhead solution if
possible. If it is non-intrusive, then it can be at least easily disabled
via configure option and one or two ifdefs in the code without sacrificing
performance for those who care.


Another point here is that it may be a good idea to update test suite to
additionally check whether the 'lazy' flags update is working correctly and the
stored flags are not getting out of sync. It would involve reusing the source
image for doing two compositing operations back-to-back, and trying to change
different properties (one at a time) in between. Not changing any properties
between these operations at all could be additionally used to check whether any
unintended garbage gets added to the flags cached in the images.

-- 
Best regards,
Siarhei Siamashka