Rendering in geode

[Huang, FrankR]

Jonathan, 

	Let me narrow down the firefox issue point. I found that that has relationship with my patch's function lx_do_composite_mask_opover()
	You know there is an EXA function exaGetPixmapPicth() which can get a pixmap's pitch.
	My method for handling PictOpOver is that 
		1)src' = src * mask
	src' is in the off-screen memory region, if the src pitch is PITCH( got from exaGetPixmapPitch), then the src' pitch is 4*PITCH( I set). 
		2)dest' = src' + (1 - alpha) * dest
	Src' is also 4 * PITCH, and dest picth is also gotten from exaGetPixmapPitch() function.
	The reason I use 4*PITCH is that the src is A8 picture, and the src' format is ARGB32, so it is 4*PITCH. I don't know if that is reasonable to appoint that pitch directly instead of exaGetPixmapPitch().
	Code details, see below.





------------------------------------------------
+static void
+lx_do_composite_mask_opover(PixmapPtr pxDst, unsigned long dstOffset,
+    unsigned int maskOffset, int width, int height) {
+    int apply, type;
+    struct blend_ops_t *opPtr;
+
+    /* Wait until the GP is idle - this will ensure that the scratch buffer
+     * isn't occupied */
+
+    gp_wait_until_idle();
+
+    /* Copy the source to the scratch buffer, and do a src * mask raster
+     * operation */
+
+    gp_declare_blt(0);
+    opPtr = &lx_alpha_ops[(exaScratch.op * 2) + 1];
+    gp_set_source_format(CIMGP_SOURCE_FMT_8_8_8_8);
+    gp_set_strides(exaScratch.srcPitch * 4, exaScratch.srcPitch);
+    gp_set_bpp(lx_get_bpp_from_format(CIMGP_SOURCE_FMT_8_8_8_8));
+    gp_set_solid_source(exaScratch.srcColor);
+    gp_blend_mask_blt(exaScratch.bufferOffset, 0, width, height, maskOffset,
+	exaScratch.srcPitch, opPtr->operation, exaScratch.fourBpp);
+
+    /* Do a PictOpOver operation(src + (1-a) * dst), and copy the operation
+     * result to destination */
+
+    gp_declare_blt(CIMGP_BLTFLAGS_HAZARD);
+    opPtr = &lx_alpha_ops[exaScratch.op * 2];
+    apply = (exaScratch.dstFormat->alphabits == 0) ?
+	CIMGP_APPLY_BLEND_TO_RGB : CIMGP_APPLY_BLEND_TO_ALL;
+    gp_set_source_format(CIMGP_SOURCE_FMT_8_8_8_8);
+    gp_set_strides(exaGetPixmapPitch(pxDst), exaScratch.srcPitch * 4);
+    gp_set_bpp(lx_get_bpp_from_format(exaScratch.dstFormat->fmt));
+    type = CIMGP_CONVERTED_ALPHA;
+    gp_set_alpha_operation(opPtr->operation, type, opPtr->channel, apply, 0);
+    gp_screen_to_screen_convert(dstOffset, exaScratch.bufferOffset, width,
+	height, 0);
+}
+

--------------------------------------------------------------------




-----Original Message-----
From: xorg-devel-bounces+frankr.huang=amd.com at lists.x.org [mailto:xorg-devel-bounces+frankr.huang=amd.com at lists.x.org] On Behalf Of Jonathan Morton
Sent: 2010?6?23? 20:57
To: Huang, FrankR
Cc: xorg-driver-geode at lists.x.org; xorg-devel at lists.x.org
Subject: RE: Rendering in geode

On Wed, 2010-06-23 at 15:54 +0800, Huang, FrankR wrote:
> ...the side effect is that firefox has some characters missing.

I would suspect a bug in your "coordinate range" handling code.  It may
be related to the dimensions of individual glyphs.

Text rendering goes through the following stages:

- A fresh temporary pixmap, A8 format, is allocated and cleared.

- Individual glyphs are placed in this pixmap using ADD operation,
sourced from a large (1024x320) pixmap serving as a glyph cache.

- The complete pixmap is used as a mask for an OVER operation onto the
original target.  The source is normally a solid colour.

- The temporary pixmap is thrown away.

If you accelerate the ADD operation, it should have the same coordinate
handling as the OVER operation; areas outside images are no-ops when
Repeat is disabled.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com


_______________________________________________
xorg-devel at lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel