[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas vs Gtk/Gdk: why the difference of perfs is so important?



On Mon, 10 Apr 2006 08:31:41 +0200 Simon TRENY <simon.treny@free.fr> 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) <raster@rasterman.com> a _crit :
> 
> > On Sat, 8 Apr 2006 20:44:30 +0200 Simon TRENY <simon.treny@free.fr>
> > 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)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)