benchmarking and fonts

2005-06-03 03:45

last evening i was pointed by someone in #fluxbox to the site from raster .. the dude behind a lot of stuff, most known for enlightenment. he posted some benchmarks related to the speed of windowmanagers. to my surprise fluxbox was pretty bad. well, i know we have some issues, but that bad? i had to test that on my own. as it turned out fluxbox wasnt that bad but also not the fastest one. i find it pretty interesting that even the speediest windowmanagers do only ~ 200 windowmappings per second while a pure x is able to do ~6000 or more. so, do we have a big mojo-leak here? hehe, noone knows, we need better tools to debug that, thats for sure. before anyone of you starts a little flameware about the benchmarks: i wrote raster already and our conversation was and is pretty friendly.

UPDATE

raster tried the 0913er version of fbox and 

map_response:              MIN: 0.007149s, MAX: 0.011372, AVG: 0.009750
map_throughput:            WIN/SEC 60.559743
no-toolbar.map_response:   MIN: 0.004989s, MAX: 0.010948, AVG: 0.008049
no-toolbar.map_throughput: WIN/SEC 85.115547
and for reference my old results:
map_response:              MIN: 0.022082s, MAX: 0.027370, AVG: 0.025921
map_throughput:            WIN/SEC 14.307426

another story of fluxbox is the fonthandling. when introducing xft-fonts in fluxbox i think a lot of confusion was started: “is it antialias? what does it do? why do i have to use that?”. and the best thing was: the “antialias” switch basicly didnt toggled antialias but usage of xft fonts. furthermore fluxbox started pretty slow in utf8 locales. and we loaded fonts multiple times. i hope i ve solved all of the problems with the stuff i wrote. i ll commit it tomorrow. after that i ll look into nls- and encoding-issues. hopefully i get that one done pretty soon.

UPDATE

i commited the font stuff and it seems to work pretty neat.

^^^