Thanks for your answers, I now understand better the problem. So since evas is not able to do blitting efficiently because it is a too generic lib, maybe I can do it myself for special cases. I actually have serious performances problems with the tree and the iconbox of widgets when the viewport is big enough (lot of objects to update, and a large area of the screen to redraw). So the only way I see to do it manually is to render the content of the tree/iconbox in a buffer with the buffer engine of evas, and then do my own blitting thing, and redraw things that needs to be redrawn. The calculation of what will need to be blit or redrawn won't be so hard because those two situations are quite specific, I just have to add some restrictions, such as no animated icons for the iconbox.
Now, before trying to do that, I'd like to have your opinion to know if it will really improve the perfs: I first have to draw or just blit the content of the iconbox/tree in a buffer, and then display it in an image object. It adds a new rendering pass so maybe it will even make the perfs worst. What do you think? Simon TRENY <MoOm> Le Sun, 9 Apr 2006 10:03:38 +0900, Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> a _crit : > 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 > > > > ------------------------------------------------------- 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
