xrender accel for smedia (glamo)
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Fri Apr 11 06:08:08 CEST 2008
On Tue, 8 Apr 2008 09:21:11 +1000 Carsten Haitzler (The Rasterman)
<raster at openmoko.org> babbled:
i've done a preliminary test suite for glamo + xrender. this is special-cased
drawing paths. i have attached the binary for ARM and source tarball. :) this
will help isolate some ops, but should be used in conjunction with expedite
+xrender engine tests.
> ok. i've now modded the xrender engine for evas. it understands "16bit" as a
> special display depth target. i.e - the glamo.
> if u have a 16bpp target (rgb 565) is creates intermediate render surfaces in
> 16bit as well (unless you want destination alpha). it also makes all images
> without an alpha channel become 16bit 565 xrender images (i.e - native depth
> what does this mean?
> 1. over blends of ARGB images can be accelerated on glamo - scaling can be
> too. check matrix for identity for non-scaling and check matrix for scaled
> version. i.e - for non shear/rotated scaling:
> sw & sh are source width/height
> w & h are destination (scaled) width/height
> tx & ty are translate offsets (likely really to be 0 mostly or maybe -1 for an
> t->matrix = XDoubleToFixed((double)(sw) / (double)(w));
> t->matrix = XDoubleToFixed((double)(sh) / (double)(h));
> t->matrix = (tx * sw) / w;
> t->matrix = (ty * sh) / h;
> so detecting the matrix for a scale op is not hard.
> 2. scaled blits (no blending i.e 16bit to 16bit copy with scale) should be
> able to be accelerated on the glamo
> 3. over blends WITH a 1x1 sized render image for multiplying color (ie for
> fading etc.) should be possible to accelerate
> 4. the problem is text. this is done with format-8 (8bit) alpha masks and a
> color (1x1 xrender image/pixmap color). the problem is glamo only does 4bit
> for alpha mask color expansion. 3 choices here:
> 4.1 we fully expand in software to ARGB8888 premul, upload then over-blend
> 4.2 alpha 8 (8bit mask) images are automatically reduced to 4bit packed (yes
> test suites will fail! i know) but that means anti-aliased text with xtf (gtk,
> qt etc.) will now be fast, as will text in evas (same mechanism).
> 4.3 we support 4bit pixmaps and force the hw format to be 4bit packed and i
> can change evas to upload 4bit ximages to these pixmaps/pictures (but that
> means the format will need to be 8bit for the src, of which only 4 bits is
> our only question is - what do we do for #4.
> the rest now is in CVS (head) of evas - so pulling and building new evas
> packages should just do the trick. i have checked under xephyr in 16bit and
> all of the engine displays as expected, so i am fairly sure i havent broken
> the engine as such.
> Carsten Haitzler (The Rasterman) <raster at openmoko.org>
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4322 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20080411/571effb6/glamo-xr-test.tar.obj
More information about the openmoko-devel