[Xorg-driver-geode] Rendering in geode

[Huang, FrankR]

Jonathan,

	Another time to bother you.
	I have added code to lx_exa.c file for geode to handle the special condtion(source coordinate is outside the image). And the main misrendering bug is solved. I am adding code just for PictOpSrc and PictOpOver. Do I need care about other ops? Till now, I have not met other ops still in this special condtion.
	Another special condition is that srcX and/or srcY is negative. You mentioned that in the mail below. From my experiment, it is a little different from the condition above.
	1)If Repeat is zero(0), the dest cooridante is calculated by the negative srcX and/or srcY.
	2)If Repeat is one(1), the coordinate is wrapped back into the
image using the modulus (%) operation. But the direction is opposite. Take an example we should do source.width - (srcX % source.width).
	These two conditions, I need your confirm.
	
	After that, I have met the mixed condtion. Take an example, srcX is negative and srcY is greater than source.height. Very interesting, we need handle this too.


Thanks,
Frank

> -----Original Message-----
> From: Jonathan Morton [mailto:jonathan.morton at movial.com]
> Sent: 2010?6?14? 18:07
> To: Huang, FrankR
> Cc: xorg-devel at lists.x.org; xorg-driver-geode at lists.x.org
> Subject: RE: Rendering in geode
> 
> On Sun, 2010-06-13 at 16:47 +0800, Huang, FrankR wrote:
> >         You know when the driver does the composite, it is called in
> > exaTryDriverComposite() function. You guess what? It give a driver a
> > composite call that the source's width is less than srcX. That is
> > impossible from my point.
> >         Make is more simple:
> >         A XRenderComposite() call below:
> >                 XRenderComposite(dpy, PictOpOver,
> > picture_10x10[0].pict,
> > 0, win->pict, 11, 0, 0, 0, 50, 50, 40, 40)
> >
> >         The source is a 10x10 pixmap, but the srcX is 11. The
> > rendering
> > result is none! I think the driver should refuse that parameter to do
> > the rendering. It will bring chaos operation. That is my thought.
> 
> Source (and mask) coordinates are allowed to go outside the image
> involved - both positive and negative.  The effect of this depends on
> the Repeat attribute on that image.
> 
> If Repeat is None (0), then samples outside the image return the
> all-zeroes vector, even if the image doesn't have an alpha channel.
> This is then sent through the rendering equation as normal.
> 
> If Repeat is Normal (1), then the coordinate is wrapped back into the
> image using the modulus (%) operation.  This is your usual repeating
> tile function.  As a special case, a 1x1 image with Repeat set to Normal
> is the usual way of representing a solid colour.
> 
> Repeat values of Extend (2) and Mirror (3) are also possible.
> 
> Obviously, you should reject attribute values that you cannot support.
> But it might happen that the hardware doesn't know how to do the None
> mode properly by itself, and failing to support that at CheckComposite
> time is pretty useless - but you don't know the coordinates until after
> that point.
> 
> Let's suppose you support the Src and Over modes.  These need to be
> handled differently if the coordinates can fall outside the source
> image(s) in No-Repeat mode: Src turns to a fill of the all-zeroes
> vector, and Over turns into a no-op.  You can therefore divide the
> rendering area into "normal" and "blanked" zones, and issue separate
> commands to the hardware for each.
> 
> Because Clear mode doesn't use the source or mask data at all, it is
> unaffected by this quirk - but it is rarely used.  Other modes have
> similar simplifications as Src and Over.
> 
> --
> ------
> From: Jonathan Morton
>       jonathan.morton at movial.com
> 
>