Carsten Haitzler (The Rasterman) wrote: >>The non-scaled onscreen XRender went from 9.7 to 0.7 seconds... :) >>(imlib is at 2.3 seconds). The scaled versions are not accelerated, and >>they all are much slower than Xrender... > > cool. though 0.7 vs 2.3 for imlib2 still isn't that good. i'd expect hardware to > be a factor of 10 or more faster these days. from having used opengl in evas (as > opposed to imlib2 in the older code engine) on a geforce1 i was getting easily > 20 times speedups for such ops.
The hardware I am working with is not famous for being fast, and it uses a shared framebuffer architecture. I stopped dreaming about miracles a long time ago. (I think that was when I found out that drawing trapezoids using the engine is slower than doing it by the CPU) What values do you get on your hardware? (Unscaled only, the rest is entirely depending on the CPU) > basically - avoid copying the pixel data aroudn or changing its format if you Yey, thanks for enlighting me :) > can (ie if you put it through the 3d engine you may have to reformat the pixels > due to in-memory texture formats being "strange"). so i'd try and keep the > pixels wherever they were last in the format they were in last - all the time, > so a blend or scaled composite/blend is literally 1 hardware op and not much > more. I need to copy the texture to video RAM once, unless somebody tells me it already is there (I could use the 2D accelerator for this, too, then. In this case I just wonder why the mga driver doesn't do it this way.). Since the accelerator does not sync after initiating the command, using the provided memory area is unsecure. The app might reuse it for something else before the command is actually executed. Syncing after the command is insane (because it could take forever, depending on the amount of commands already in the queue - and this queue is BIG) > i don't actually know how you are doing it currently, so i'm just saying this as > a general thing - but somehow i'd still expect hardware to be more than 3.3 > times faster than the cpu :) It's a fast CPU with fast RAM, and a slow GPU with memory shared with the CPU. More can't be expected, I guess. Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) >>Since the hardware I' dealing with supports stretched bitblits, I'll >>look if that could be made of any use. > > ich freue mich schon darauf :) You live in Australia, have a german sounding name, speak German... any special reason for using this icky JP font? >>Is it correct to assume, that the image I see over a rainbow-like >>background is the result of RENDER, and over a grey-shaded background >>from imlib? > > > check the .png's in the directory. > > tst_opaque.png > is set as the background to the window before doing any compositing > and testing. this is done for both xrender and imlib2. it' sjust a > "test background". Hm, the background never looks like that gfx during render tests. I just see a rainbow-like gradient from top/left to bottom/right... (no matter whether with or without the accleration) > you will notice for about 2 seconds after each imlib2 test completes > it displays its work on the screen in the window. this is just to let > you know that imlib2 did the right thing. I changed these delays to check if the rendering is ok. It actually is, it looks EXACTLY like the imlib result. :) > the code is fairly straight-forward and modular too if you want to > fiddle with it, disable tests for now etc. Been there, seen that, done that. :) > good... and scaled woudl be lurvely! :) That could be a problem. So far, I haven't found a suitable hook for this (and replacing the entire composite function seems a bit far fetched at the moment) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
