[cairo] pixman: New ARM NEON optimizations

Siarhei Siamashka siarhei.siamashka at gmail.com
Mon Dec 7 02:06:05 PST 2009

On Wednesday 02 December 2009, Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > 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 again?
> As long as the X server is creating and destroying images all the
> time, I don't think it makes a lot of sense to optimize pixman for
> tiny images.

X server is an important pixman user, but it is not the only one. Cairo with
image backend is one of the examples.

Removing delegates just:
1. makes code smaller
2. makes it a bit faster

Here is a branch for delegates removal (for pixman_blt so far)
This can be also easily done for pixman_fill and combiners.

This issue definitely starts taking much more time than it is deserving (it's 
not something critical, but just a kind of low hanging fruit). If it's a no
go and delegates are going to stay, then I'm done with it and will stop
spamming here.

The point is that the delegates are easy to remove and they are easy to add if
really needed. Right now they have no practical use, but slow down code and
clutter it a bit.

> When the X server is fixed, it would make a lot of sense to look into
> how to get pixman to deal with tiny images, whether they are glyphs or
> just small, general images. The flags branch helps a bit with that,
> but there is still overhead on some profiles.

I'm not sure if it is easy to fix X server properly. Keeping an extra
pixman_image_t copy for each picture and doing lazy updates for it is going to
increase memory overhead (pixman_image_t itself is larger than 300 bytes).
With lots of small images (those which should benefit the most) extra storage
overhead becomes quite apparent. There could be other solutions tried but this
is better to be discussed on xorg-devel list.

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/20091207/cf8d4df3/attachment.pgp 

More information about the cairo mailing list