Some stupid widget toolkits benchmarks
Moderator: MaxCoderz Staff
Some stupid widget toolkits benchmarks
Existing widget toolkit libraries didn't do it for me. Luckily, I know how to program so I made my own. Of course, I had to accelerate it all with the graphics card, which isn't that spectacular code-wise but it usually helps a lot. I hoped I could match the speed of some of the existing libraries and so I did some very simple and stupid benchmarks.
I got a menu with submenus and I thought I'd go crazy with the mouse pointer over the menu items in my own application ukenaz (an editor with plugin sub-editors) and a couple of other programs.
Firefox with its stupid js-menus or whatever takes more than 30% of CPU resources combined with Xorg. Didn't really surprise me.
GIMP did a bit better at 12%.
Exhibit, a picture viewing program using ETK from the guys who makes E17, took 10%, and every highlight is fully animated with bling bling effects and what have you.
My brother tried the Java menus in Sun Studio in Solaris and reported 9%, but after the menus had been cached somehow, it was down to 5%.
The above values were acquired with 'top' in linux (except sun studio of course). When I tried ukenaz, it didn't show up in the list (it took 0% CPU resources) and Xorg took 1%.
And that's it.
I got a menu with submenus and I thought I'd go crazy with the mouse pointer over the menu items in my own application ukenaz (an editor with plugin sub-editors) and a couple of other programs.
Firefox with its stupid js-menus or whatever takes more than 30% of CPU resources combined with Xorg. Didn't really surprise me.
GIMP did a bit better at 12%.
Exhibit, a picture viewing program using ETK from the guys who makes E17, took 10%, and every highlight is fully animated with bling bling effects and what have you.
My brother tried the Java menus in Sun Studio in Solaris and reported 9%, but after the menus had been cached somehow, it was down to 5%.
The above values were acquired with 'top' in linux (except sun studio of course). When I tried ukenaz, it didn't show up in the list (it took 0% CPU resources) and Xorg took 1%.
And that's it.
FLTK is very fast and very small (and it's hw-acc!), took only a couple of minutes to compile the entire thing including all demos (my plugin kernel, all plugins plus ukenaz takes 7s to compile, and that includes half of a 3d engine). The menu demos did well with 0+1% (version 1.1) and 1+3% (version 2.0). I haven't looked into this toolkit a lot, dunno why it isn't used. How well does it run without hw-acc?
A very small sample program with GTK runs at 4+4%.
I don't have Windows 98 around, besides this test I do is pretty stupid What I find weird is that a total of a couple of days work has produced a pretty well performing GUI, where are the hw-variants of the more popular GUIs? And no, it's not unnecessary with hw-acc, I don't want graphical programs to steal CPU resources just because I browse menus while some other important process chugs along.
A very small sample program with GTK runs at 4+4%.
I don't have Windows 98 around, besides this test I do is pretty stupid What I find weird is that a total of a couple of days work has produced a pretty well performing GUI, where are the hw-variants of the more popular GUIs? And no, it's not unnecessary with hw-acc, I don't want graphical programs to steal CPU resources just because I browse menus while some other important process chugs along.
The GUI is a plugin in my long-going plugin kernel project, so whenever I get to finish off ukenaz, you'll see the GUI.
Straight from "cat /proc/cpuinfo":
Straight from "cat /proc/cpuinfo":
Code: Select all
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 31
model name : AMD Athlon(tm) 64 Processor 3000+
stepping : 0
cpu MHz : 1000.000
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up lahf_lm ts fid vid ttp
bogomips : 2002.51
clflush size : 64
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
I opened up a terminal, started top, opened up the Tools menu in Firefox with a blank page and then twitched the mouse up and down.
As I said, the test is pretty stupid and the actual figures mean hardly anything, but a coarse comparison of 1% to 30% in CPU usage says a little.
Java isn't slow, it's just not as fast or as versatile as some ambitious C
As I said, the test is pretty stupid and the actual figures mean hardly anything, but a coarse comparison of 1% to 30% in CPU usage says a little.
Java isn't slow, it's just not as fast or as versatile as some ambitious C
That kind of test is a bit different, because submenus are opened a closed rapidly and pretty much the entire window needs to be redrawn all the time. For static menu popups, only the submenus should need a redraw. I haven't bothered with that little optimization myself, since the GUI is hw-acc:ed and the sub-editors pane will mostly be a 3D view anyway.
Plus my own GUI uses GUI renderers to draw things, they can actually use the shader-based renderer for 3D GUIs with all the neat graphics effects available to the 3D world, so supporting partial redraws for that can turn out a bit tricky :p No point I guess, 'cause a GUI in 3D will most probably be riddled with effects and not be still.
What I don't understand is why the GUI can "take so much CPU", especially for such wide-spread GUIs.
Plus my own GUI uses GUI renderers to draw things, they can actually use the shader-based renderer for 3D GUIs with all the neat graphics effects available to the 3D world, so supporting partial redraws for that can turn out a bit tricky :p No point I guess, 'cause a GUI in 3D will most probably be riddled with effects and not be still.
What I don't understand is why the GUI can "take so much CPU", especially for such wide-spread GUIs.