[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 Sun, 2006-04-09 at 10:03 +0900, Carsten Haitzler wrote:
> 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".

If on the other hand you choose to test the canvas' using something like
image scaling or evas_bench style animation you'll notice that evas is
faster ;)
http://www.linuxjournal.com/article/8213

These tests also cover the case of having to redraw much/most of the
canvas.

Attachment: signature.asc
Description: This is a digitally signed message part