On 13 May 2010 03:03:47 +0200, Soeren Sandmann <[email protected]> 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. -- [email protected]
pgp6FafkEkhtU.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
