[PATCH 2/2] fb: Adjust transform or composite coordinates for pixman operations
Soeren Sandmann
sandmann at daimi.au.dk
Wed Dec 9 16:27:33 PST 2009
Keith Packard <keithp at keithp.com> writes:
> Sorry for replying to myself again -- I meant to describe the effect of
> this patch on source operands.
>
> What this does is use the entire pixmap as the source operand and then
> adjust either the source transform (if present) or source coordinates to
> fetch pixels from the right part of that pixmap.
>
> So, this gets the right pixels for source coordinates within the source
> window. What it doesn't do is get the right pixels for anything
> else. None of the repeat modes work, and pixels falling outside of the
> window, but inside the pixmap will get whatever was in the pixmap at
> that location.
>
> To make the repeat modes work, we'd need to provide a rectangle
> describing the projection of the window into the pixman_image, then
> replace all of the existing pixman_image-based clipping with clipping
> based on the window. This can be done in a backwards compatible
> fashion by setting the clipping to the bounds of the pixman_image by
> default and exposing a new API for source clipping.
>
> We could also make source clipping work by performing point-in-region
> computations for every source pixel fetch; one suspects that might be a
> bit too expensive for most applications though.
I can't say I particularly like this, since it doesn't really work in
a number of cases.
While there were issues with the copying approach, at least it did get
the right answer except in the case where an a1 (or other < 8 bpp)
pixmap would not be at (0, 0) within its enclosing pixmap. (When does
that happen btw?)
I think the performance issue with the copying could be fixed by only
copying the bounding box of the pixels in question.
On the other hand, there has been talk about subsurface support in
cairo. For that to become a reality, it seems pixman will have to
support clipping based on < 8 bpp pixels anyway, as complex as that is
going to be.
So I guess I'm fine with these patches.
Soren
More information about the xorg-devel
mailing list