[Xorg-driver-geode] Rendering in geode

[Huang, FrankR]

Jonathan, 

	See below based on your comments.
	One [Frank] place.

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.

[Frank] I found that the region rendered actually is the width x height in this condition. I don't find the modulus operation. Any comments?

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