On Tue, 8 Apr 2008 09:21:11 +1000 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> 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 > 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) <[EMAIL PROTECTED]> > -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
glamo-xr-test.tar.gz
Description: Binary data
