On Sat, 8 Apr 2006 20:44:30 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> Hi, > > I ran on my P3 1Ghz a small (stupid) test to compare Evas and Gdk > performances: with Evas, I displayed a big image (1600x1200) in a > smaller window (1300x1100) and I dragged the image quickly with the > mouse. The dragging was laggy and the cpu usage was almost 100%. I then > ran exactly the same test with gqview (a gtk image viewer) with the > same image and the same viewport size (1300x1100). There, the dragging > was smooth and the cpu usage around 50%. > > I know this test is not representative (it shows a special case with no > accurate results) but it just illustrates the feeling I have: evas > seems a lot slower than the renderers of Gtk and QT, when it has to > refresh a big part of its viewport. Of course, using the GL engine > improves the perfs a lot, but the comparison doesn't make sense > anymore: Evas is hardware-accelerated while Gtk is not. of course! i have known this ever since. "scrolling" is evas's weak point. also note GDK USES x's drawing calls whihc probably sue hardware to fill in solid colors - and the last thing... it uses hardware to BLIT (copy pixels from one area to another) when scrolling. evas does a full redraw with the cpu (with you have the software engine). i have known this ever since and actually have warned people many times "but evas will suck for scrolling". basically when you move an object - evas calculates when changed and just REDRAWS that. gtk/gdk are immediate-mode. you scroll and they blit regions of the framebuffer. they don't redraw - or if they do often it is actually already partly accelerated by the hardware for solid fills, and pixmap copies. evas has no code to "detect" blits - it is, in theory, possible to take N objects that change state (move, resize, change color etc. etc.) and then calculate what regions of the screen can be blitted, what are to be left alone, and which need full redraws. i actually have experimental code to do this - BUT it is significantly more "Expensive" to calculate this than to just calculate a redraw. so what happens is - we spend a lot more cpu (about 20 times more cpu) than the simpler tiled update buffer evas uses now. so - we would save cpu by replacing some redraws with blits, but spend more cpu calculating it. also this experimental code isn't PROVEN to be correct yet - it may make mistakes in calculations etc. so i am hesitant so go wholesale add it into evas. but basically - the problem you are seeing is blitting. when images are solid and many images move together - then you can blit, but if they are semi-transparent with alpha and move across something that doesn't move with them, you have no choice by HAVE to redraw due to alpha blending requiring that. > I'd just like to know why the difference is so important? Is Gtk > somehow hardware-accelerated (xrender?), or is it because Evas and Gdk > just do not do things the same way? I don't think the rendering > routines of Evas are to blamed since they seem even more optimized > than what other libs use, I just don't understand the difference of > perfs. > Can you tell me more about that? > > Regards, > Simon TRENY <MoOm> > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
