[cairo] pixman: New ARM NEON optimizations

Siarhei Siamashka siarhei.siamashka at gmail.com
Thu Nov 5 13:56:45 PST 2009

On Thursday 05 November 2009, Soeren Sandmann wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> > Excerpts from Siarhei Siamashka's message of Wed Nov 04 16:36:21 +0000 
> > > In any case, simple functions which use only basic data types as
> > > arguments (nothing like pixman_image_t) and has no checks for clipping
> > > or whatever else can be used from the other libraries efficiently.
> >
> > +1. ;-)
> >
> > I could also use a pixman-core, though the overhead after applying
> > Søren's flags branch is not large enough to justify the effort, yet.
> The case where pixman has a lot of overhead is glyphs, which is why
> pixman needs explicit support for that.
> If you have other use cases than glyphs, I'd be interested in hearing
> about them.

It is quite easy to construct such a case. For example a simple demo program
which renders really lots of small particles (to get some nice visual effect)
using images with alpha transparency.

It's kind of chicken/egg problem. Slow operations do not get proper
optimizations because they are not used in real applications. And application
developers probably avoid these slow operations just because ... they are
slow :)

As you noticed earlier, software RENDER extension implementation in xserver
suffers from creating and destroying temporary pixman_image_t structures for
each operation in fbComposite function (PicturePtr and pixman_image_t are
practically duplicates of each other). But this is not a good excuse to be
wasteful regarding CPU cycles in pixman too. If anything can be simplified and
optimized even a bit with relatively little efforts, probably this should be
done. Or is it better to fix xserver first and then look at pixman performance

Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cairographics.org/archives/cairo/attachments/20091105/e4559435/attachment.pgp 

More information about the cairo mailing list