Pixman Accessors
Aaron Plattner
aplattner at nvidia.com
Tue Jun 9 16:44:26 PDT 2009
On Tue, Jun 09, 2009 at 09:50:05AM -0700, Soeren Sandmann wrote:
> Pixman has a feature where you can set accessor functions on an image
> and all pixel access will then go through those functions. It's used
> exclusively for wfb.
>
> Until now this was implemented by compiling the pixel accessors twice,
> with a READ macro defined in two different ways. This is annoying for
> several reasons, so instead I want to just make a copy of the image
> before compositing, and then copy back afterwards.
>
> Does anyone see a problem with this? Performance is not a concern at
> all. It was slow before and it will be slow after.
I know performance is not a concern, but if you're going to copy the entire
image to malloc memory, it would be faster to use GetImage/PutImage (or
some new pair of similar hooks) and get the GPU to do it than to grab it
directly through the low-level accessors. Obviously that wouldn't work on
implementations where GetImage falls back to pixman, but there could be a
default fallback to the low-level accessors or something if necessary.
Changing the libwfb interface to make it easier would probably help. I've
been meaning to free up some time to look into making the accessor
interface a little more sane, but you know how that goes... It would be
nice if libwfb could know on a per-drawable basis whether it needs to use
the wrappers or not. Back in the day, that would have required a total
rewrite of libfb, but maybe it's easier now with pixman. If not, it might
be worth doing the work anyway.
One thing to keep in mind is that surfaces could be up to 4GB in size, so
if you can avoid grabbing the whole thing using region or bounding box
tricks, that would help a lot. Of course, if you're falling back to
software rendering to 32kx32k surfaces, you lose anyway.
> Patch here:
>
> http://www.daimi.au.dk/~sandmann/access-denied.patch
>
> and git repo here:
>
> http://cgit.freedesktop.org/~sandmann/pixman/log/
>
>
> Soren
More information about the xorg-devel
mailing list