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....@lists.x.org
[mailto:xorg-devel-bounces+frankr.huang=amd....@lists.x.org] On Behalf Of
Jonathan Morton
Sent: 2010?6?23? 20:57
To: Huang, FrankR
Cc: xorg-driver-ge...@lists.x.org; xorg-devel@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.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
_______________________________________________
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
