On Mon, 10 Apr 2006 08:31:41 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> 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). really - you will use up a lot of ram for that - and likely only get a bit better performance. there is a combination of problems here. 1. moving LOTS of objects - but mostly 2. redrawing lots instead of blitting. 2. is the biggest problem by far. > 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? doing it yourself likely won't help a lot in the end. to get to the "Screen" evas will STILL do a redraw of that whole region. you need to really be thinking of having evas detect blits. but thats is NOT a simple task - trust me. i have code that does it - in theory, but the actual rect logic needs a LOT of optimizing. > 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 > > > > > > > > -- ------------- 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
