On Sun, 2006-04-09 at 10:03 +0900, Carsten Haitzler wrote: > 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".
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.
signature.asc
Description: This is a digitally signed message part
