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

[Carsten H. (T. R. <ra...@ra...>]

On Sat, 8 Apr 2006 20:44:30 +0200 Simon TRENY <sim...@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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多
Tokyo, Japan (東京 日本)