[Xorg-driver-geode] Rendering in geode
Huang, FrankR
FrankR.Huang at amd.com
Fri Jul 30 02:47:21 PDT 2010
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.com at lists.x.org
> [mailto:xorg-driver-geode-bounces+frankr.huang=amd.com at lists.x.org] On
> Behalf Of Jonathan Morton
> Sent: 2010?6?14? 18:07
> To: Huang, FrankR
> Cc: xorg-driver-geode at lists.x.org; xorg-devel at 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.morton at movial.com
>
>
> _______________________________________________
> Xorg-driver-geode mailing list
> Xorg-driver-geode at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-geode
More information about the xorg-devel
mailing list