xrender accel for smedia (glamo)

Carsten Haitzler (The Rasterman) raster at openmoko.org
Tue Apr 8 01:21:11 CEST 2008


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
pixamps).

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:

where:

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
offset).

   t->matrix[0][0] = XDoubleToFixed((double)(sw) / (double)(w));
   t->matrix[1][1] = XDoubleToFixed((double)(sh) / (double)(h));
   t->matrix[2][0] = (tx * sw) / w;
   t->matrix[2][1] = (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 used)

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>



More information about the openmoko-devel mailing list