[PATCH] render: Avoid infinite loops in alpha map handling (#23581)

[Keith Packard]

On 13 May 2010 03:03:47 +0200, Soeren Sandmann <sandmann at daimi.au.dk> wrote:

> It's not really well defined if the alpha origin is different from 
> (0, 0), though.

Good point.

> > The problem with the other case is that you can *later on* change
> > the picture used as an alpha map to add an alpha map there.
> 
> Can we simply say that if an image has an alphamap with an alphamap,
> then you get BadMatch from Composite and the other Render ops?

Oh, just check at composite time up front. Yes, that will work.

> The problem is if the underlying *drawable* is the same. When storing,
> the RGB channels will first be written to the drawable, and then the
> alpha channel will be written, which will overwrite the RGB
> information. (Since pixman doesn't guarantee that x channels will be
> left alone for performance reasons).

I would fix this up in the server so that pixman would see NULL for
alphaMap but for the origin.

> If the alpha map has a non-zero origin relative to the picture, the
> behavior gets even more unpredictable.

BadMatch seems like the best answer here. I'm not happy about having the
composite operations return BadMatch, but the alternative is keeping
track of whether a picture is being used as an alphaMap by some other
picture, and I don't think we want to go to that much trouble.

-- 
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/20100512/cf4bbf2c/attachment.pgp>