Morton,
From your explanation and my test with rendercheck, I found it more
complex for the driver to handle these special condition.
Give the results I tested PictOpOver with the following
XRenderComposite() call in Xlib app on ATI X1200.
1)XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0,
win->pict, 11, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has repeat
attribute.
Result: 30x30 rendering region
2) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0,
win->pict, 11, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has no repeat
attribute.
Result: no-op
3) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0,
win->pict, -10, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has repeat
attribute.(negative coordinate)
Result: 30x30 rendering region
4) XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0,
win->pict, -10, 0, 0, 0, 50, 50, 30, 30) with the picture_10x10 has no repeat
attribute.(negative coordinate)
Result: 10x10 rendering region
Just as you told me in the mail, the source coordinate is allowed to be
outside of the image--positive and negative. In 1)-4), I gave the both tested,
you can see the result.
That is only the PictOpOver, I gave a test to PictOpSrc. The result is
as you said, black region with no repeat parameter(zero vector).
What I want to ask is that does driver need handle these all? I think
it is a huge burden for the driver to judge. Why the server gave such
parameters to driver? Maybe one of this special condition can make the driver
rendering result fails, just as geode. And the most important thing is that, if
the driver found it can not do that rendering, it is to late for put the
rendering back to Xserver SW method.
I can add some code to this special condition, but these questions
above puzzle me.
Thanks,
Frank
-----Original Message-----
From: Jonathan Morton [mailto:jonathan.mor...@movial.com]
Sent: 2010?6?14? 18:07
To: Huang, FrankR
Cc: xorg-devel@lists.x.org; xorg-driver-ge...@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.mor...@movial.com
_______________________________________________
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
