[PATCH 2/2] fb: Adjust transform or composite coordinates for pixman operations
Keith Packard
keithp at keithp.com
Fri Dec 11 11:58:33 PST 2009
On 10 Dec 2009 01:27:33 +0100, Soeren Sandmann <sandmann at daimi.au.dk> wrote:
> I can't say I particularly like this, since it doesn't really work in
> a number of cases.
Yeah, anytime the source coords go outside the window geometry, it
generates fairly bogus data. Fixing pixman to allow for sub-region
sources didn't look very hard though, and would eliminate this remaining
issue. At present, pixman implicitly clips at 0,0 - w,h; we'd just need
to change the implicit clip to an explicit clip.
> 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?)
The copying approach should always have gotten a reasonable answer; it
was the original code which tried to adjust pixmap base addresses.
> I think the performance issue with the copying could be fixed by only
> copying the bounding box of the pixels in question.
That would certainly make it 'less bad'
> 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.
I've attached an 'Acked-by:' and pushed them to master. Thanks for
helping out.
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091211/88bb5b16/attachment.pgp
More information about the xorg-devel
mailing list