Jonathan, How about the rendering process if the coordinate is negative? How the driver handle this condition? By the way, I have done the condition when the coordinate is greater than source(using modulus first). Is it workaround for all ops? I just implement the PictOpOver.
Thanks, Frank > -----Original Message----- > From: xorg-driver-geode-bounces+frankr.huang=amd....@lists.x.org > [mailto:xorg-driver-geode-bounces+frankr.huang=amd....@lists.x.org] On > Behalf Of Jonathan Morton > Sent: 2010?6?14? 18:07 > To: Huang, FrankR > Cc: xorg-driver-ge...@lists.x.org; xorg-devel@lists.x.org > Subject: Re: [Xorg-driver-geode] 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.mor...@movial.com > > > _______________________________________________ > Xorg-driver-geode mailing list > xorg-driver-ge...@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-geode _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel