Jonathan,
Miss this mail but find in the http://lists.x.org/archives/xorg-devel
I have some understanding about your explanation. Is that to say if the
source pixel is out of the source image, the modulus operation will be used to
get the source pixel to to rendered, not for the rendering region. Take my
example, the srcX is 11. So after the modulus operation, the source pixle used
to rendering is (11%10, 0), that is (1,0). And because the rendering region is
40x40, so it will wrap back the (0,0) of the source image for the continuing
rendering. Is that correct?
Thanks,
Frank
On Mon, 2010-07-12 at 09:52 +0800, Huang, FrankR wrote:
> picture_10x10[0].pict = XRenderCreatePicture(dpy,
> picture_10x10[0].d, picture_10x10[0].format, CPRepeat, &pa);
> XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0,
> win->pict, 5, 11, 0, 0, 0, 0, 40, 40);
>
> The source picture is 10x10 region and is repeatable, the srcX is 5
> and srcY is 11(greater than 10), the needed rendering region is 40x40.
> After this is executed, actually a region of 40x40 is rendered. I have
> not see the modulus(%) operation. For example 11%10 = 1 ... So what's
> your mean about the modulus operation?
The modulus operation is used (in Repeat mode) to determine which source
pixel is used for each destination pixel. It does not determine the
number of pixels to be rendered, and neither does the dimensions of the
source image.
This is in contrast to some other rendering systems, which use the
source dimensions (possibly remapped in some way) to determine the
rendered area.
> So my question is that in this condition, how the destination region
> is rendered? It is important for me. From the experiment, I found it
> is 40x40 region rendered.
The destination region, as I mentioned, is specified explicitly by the
dx,dy,dw,dh parameters. For every pixel in this region, a source pixel
is determined to match it.
If that source pixel is outside the source image, then in normal Repeat
mode, it is remapped to a point inside the image by repeatedly adding or
subtracting the appropriate source image dimension (ie. the modulus
operation).
If Repeat is turned off, then source pixels outside the image bounds are
instead treated as the all-zeroes vector as previously explained.
The above applies equally to mask images if present.
The resulting pixel is then applied to the blend operation.
-----Original Message-----
From: Huang, FrankR
Sent: 2010?7?12? 9:52
To: 'Jonathan Morton'
Cc: [email protected]; [email protected]
Subject: RE: [Xorg-driver-geode] Rendering in geode
I think I do not make the question clear.
Let me take an example:
picture_10x10[0].pict = XRenderCreatePicture(dpy, picture_10x10[0].d,
picture_10x10[0].format, CPRepeat, &pa);
XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win->pict,
5, 11, 0, 0, 0, 0, 40, 40);
The source picture is 10x10 region and is repeatable, the srcX is 5 and srcY is
11(greater than 10), the needed rendering region is 40x40.
After this is executed, actually a region of 40x40 is rendered. I have not see
the modulus(%) operation. For example 11%10 = 1 ... So what's your mean about
the modulus operation?
So my question is that in this condition, how the destination region is
rendered? It is important for me. From the experiment, I found it is 40x40
region rendered.
Thanks,
Frank
-----Original Message-----
From: Jonathan Morton [mailto:[email protected]]
Sent: 2010?7?10? 0:34
To: Huang, FrankR
Cc: [email protected]; [email protected]
Subject: RE: [Xorg-driver-geode] Rendering in geode
> > 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.
>
> I found that the region rendered actually is the width x height in
> this condition. I don't find the modulus operation. Any comments?
The destination region is always specified explicitly as (x,y)(WxH).
The source and mask pixels used can vary.
--
------
From: Jonathan Morton
[email protected]
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
