After benchmarking an extensive set of Window Managers for X, we have found that Enlightenment DR17 comes out on top in terms of speed. The benchmark was performed on old (FVWM) and new (Metacity, new KDE / KWin) window managers and rated them in terms of window mapping and response time. The bechmark can be found here (both results and source).
I can’t wait to install dr17 on Ubuntu Hoary. I’ve also read up on dr17 and someone who finds it usefull on slow cpu’s with 3d cards. Linux on top again for dusty ‘puters.
what can i say, E rules! i can’t wait to get a stable E17 release
, nice work Raster and you other guy’s…..
Does anyone know how to set up (ALT + TAB) to change between Windows in E17 ?
Within KDE I can copy domething from the browser, open kterm and paste it into a file. Is this something that belongs to kterm, kde ? How to do this within e17 ?
Have you tried firefox within e17. Whenever I want to download a file, firefox crashes, ONLY within e17
E always was and still is a gross hack. Who is going to use
this crappy wm when the future of the linux desktop lies
on OpenGL ? The software/fake/hack-alike drop shadows look
nice in E17 but all they are is a hack. I am not impressed
by the architecture, or the complete lack of opengl support
and disregard as to the direction the linux desktop is taking.
wow, i am really suprised that fluxbox is near the bottom!
anyone know why?
-best
Within KDE I can copy domething from the browser, open kterm and paste it into a file. Is this something that belongs to kterm, kde ? How to do this within e17 ?
What do you mean with this? Copy/Paste is dependent on X, not KDE or anything (especially not kwin, kde’s window manager).
So, copy/paste between your browser and terminal must work in E17 exactly like it works in kwin.
Now that’s a surprise… In the first test it’s way slower than kwin amd metacity! Weird…
Read “hardware-accelerated”
http://www.enlightenment.org/Libraries/Evas.html
AFAIK, E(vas) can also draw on OpenGL, but more importantly it can also draw on cairo.
But the results should be taken with a grain of salt.
First, this is only about showing a window. How many new windows do you get if you launch a new application? One? Ten, if the app happens to be GIMP? I don’t think the WM would be a bottleneck in such case, and spending a few more milliseconds on all the features with a better (whatever your personal definition of that is) WM doesn’t necessarily have to be a bad bargain.
Second, there seems to be a noticeable noise in the results that skews them. If you look e.g. at KWin and KDE entries, KWin alone should be faster than full KDE, but in the first graph it’s actually the other way around. Similarly, the second graph should be just an 1/x of the first one, so if Xwfm4 needs slightly more than 0.01s to map one window, how come it can map only 5 of them within a second?
And finally, one thing worth nothing is that the E17 entry that actually seems to matter is not the best one, but the “E17 (CVS)” entry, which is no longer the best. I have no idea what E17 modules are, but the best entry seems like severely crippled version of E17.
That said, perhaps I’ll find some time to play with it myself.
>What do you mean with this? Copy/Paste is dependent on X, not >KDE or anything (especially not kwin, kde’s window manager).
>So, copy/paste between your browser and terminal must work in >E17 exactly like it works in kwin
Well it doesn´t work on my current e17 desktop, that´s the reason I ask
mmm, yep /me switched from gnome 2.8 to fluxbox because gnome is too slow for my machine (imho).
so I’m surprised to see it the bottom of all stats :/
p.s.
running free with fluxbox I have no more than 30mb of swap with gnome I had up to 100…, also for example the clock applet, not sure how it’s called, consume often cpu time (maybe every second ? ) and a lot of mem (20% of ram running the top, if i remember right).
my sys is 128mb ram, celeron 400
for my usage, jedit some firefox browsing and an open terminal to compile some h8300 g++ stuffs, fluxbox is speedy and consume less memory, and less disk accesses (a lot of less swap)
I’m also surprised, but looking at that list, I found “xfwm4” and “XFCE 4.0.6”?!? So, xfwm4 is faster then XFCE?
This is ridiculous, at least he should know the difference between WM and DE. What’s next, Metacity is faster then Gnome?
In fact, I just saw both kwin and KDE listed.
sorry for my crappy English, also the clock applet I was referring to was the one that gnome uses to show the date/time on the top bar.
E17 seem to be the only real innovation in linux graphics. I still wait for working at full speed X RENDER extension declared 5 years ago . E17 convert my not so fast Cel300@417 + matrox g200 to powerful smooth workstation.
I think they have the results back to front
kde 3.3 faster than xfce4 – I think not
gnome faster than kde ? hmmmm marginal
gnome faster than fluxbox… I think not also
Yeah great, but how about actualy releasing the damn thing?
I think it is very well possible that KDE is faster than xfce4, due to the QT toolkit. QT is technically superior to GTK in terms of speed. And this is very well noticable in benches like this.
OK, E17 does all the things better than the others. But without the ability of trying it out (without any release, even pre-alpha) it won’t get any publicity. Even if it’s the best WM in the world…
To the people who are complaining that their favourite WM is lower than they think it should be (raver31…): Have you looked at what is actually being tested?
It’s a measure of how many windows can be opened per second – when do you *ever* open more than a couple a second? Let alone a couple of hundred?
And the second test is taking place in the 10ms region of time. Can you actually notice than when you open an app?
Of course not.
These are benchmarks Rasterman did for his own benefit to see how e was doing as a window manager. Don’t take them in a context they’re not meant to be in.
Having said that, I have a happy warm glow knowing I’m justified in my choice of e17 😛
Also take notice that Rasterman is de man behind enlightenment, so he might be a bit biased. Btw. Don’t mind my previous comment, it’s incorrect.
If you switch off shadows and E17 it still “feel pretty smooth and responsible” compared with other WM. Eye-candy is a free bonus. Yes, I have look at source. Simple, low memory using algs, speed-in-mind vs at-least-it-works as in X. Excellent work.
Funny though that there are actually options in e17 to enable opengl for the desktop – you have to find them in the code – gl is too unstable to provide them as a normal user option, and has lower rendering quality compared to software… if all you care about is the future of your high end linux desktop sure – what we do isnt amasingly bleeding edge – but we are bleeding edge ready. but on the other side – unlike the bleeding edge, we care about more than that – scaling down to embedded devices is one of them. we can do it. all the “lets all build on opengl” is not going to get you far there. even on a desktop pc, try the “opengl desktop” on an i810 gfx chip? E17 is walking a fine line between clean modularised and expandable design and still providing a good look and flexability to change it. The “future of the linux desktop” is not stable, it doesnt scale down back to your older machine and it doesn’t work on a lot of cards without closed drivers. (modern ATI and nvidia cards).
If you dig down a few levels you may find that we manage to do most things much faster than anyone else – with pure software rendering. we have an abstracted engine system to allow the sliding of a different rendering engine under the hood – easily. we have abstracted to hardware accelerateable systems – of which all are either very slow, have lots of software fallbacks in many case, or are unstable. We have an OpenGL rendering engine already – a half-done cairo one (cairo ended up about 20 times slower than evas with its own software rendering given the state of the engine I didn’t continue as it was not worth it). We support qtopia, DirectFB and even the linux framebuffer directly as well as rendering to memory. I can add more engines as needed, but right now see no pressing need for one as xrender is not a speed demon until it gets a lot of fixes (I could do a complex hybrid engine of software +xrender to bypass its abysmal acceleration of non 1:1 blends – but software we have is still overall quite fast and good enough for development).
I suggest you look a bit deeper than just the surface.
The current test only points out the speeds of the window management systems. So there’s no point to compare wms to full des. I don’t think difference in speeds of wms is really that important. kwin and metacity are not the bottlenecks of kde and gnome.
I though about modding your comment down. But then I though it would be better to actually respond to what you posted. Why? I guess I just have a certain sympathy for trolls today-trolls deserve attention too!
>>E always was and still is a gross hack. Who is going to usethis crappy wm when the future of the linux desktop lies
on OpenGL ? The software/fake/hack-alike drop shadows look
nice in E17 but all they are is a hack. I am not impressed
by the architecture, or the complete lack of opengl support
and disregard as to the direction the linux desktop is taking.<<
I take it from your post that you have actually never used any of the E17 stuff no? Because if you had you would know that E17 offers the use of opengl rendering for all of it’s rendering operations. Aside from the fact the E17 includes the fastest software rendering libraries to be found anywhere in *nix Land, which means those who don’t have the good fortune to be running a opengl-supported video card still have access to the latest next-gen graphics, which is the hallmark of all things E, E is capabale of fully utilizing opengl supported hardware for all rendering.
As to being a hack….hmmm… Well the refactoring work which has gone into E17 over the past 3 years makes me think that ‘hack’ is somewhat compleltely offbase. None of the other existing wm/dm’s have had such excruciating attention paid to every aspect of the API which has formed the Enlightenment Foundation Libraries. In fact many people have been quite frequently discouraged by the apparent glacial rate of progress happeing in E17- if Rasterman and co. had been content to simply make a ‘hack’ in E17 everyone would have had something usable, in a hackish kind of way, 2 and 1/2 years ago. But we are all patiently waiting for E17 as a wm to fully materialize-the EFL libraries, when E17 is production, will probably be some of the most mature libraries ever introduced with the introduction of new new wm/dm.
‘Hack’ is a word which describe a quick ‘fix’ to a problem, one which generally does not fully address a problem, one that often only addresses the symptoms, but one which enables someone to overcome a problem or limitation quickly and cheaply- albeit the price to be paid is architectural- and this price is usually much larger in the long run. Of course ‘hack’ hqas many other connotations, but I imagine most software hackers can ressonate with what I just impromptu wrote.
If you had followed E17, as a project, since it first began-even from the sidelines (like me!), you would know that Rasterman and co. have scrapped their work and started afresh multiple times over the last 3 years. I played around with E17 first about 2 years ago and everysthing has changed so much in intervening time that there is only superficial similiarity between E177 circa 2003 and what Rasterman is now developing. If one was to have a legit critique against Rastermans approach it would be to take fault with his penchant for perfectionism-something which one normally does not associate with ‘hacks’. The relentless perfectionism has led to whole sale dumping of already developed software and continuous rewrites in a quest for some kind of elusive holy-grail of kick-ass X11 graphics.
Oh and if you ever manage to write anything as powerful and quick as imlib, which is pretty much the definition of software rendering in *nix land, please come back and post details about your project. I ‘am sure we would all love to see your contributions.
Where I will give you a little bit of credit is your pointing to the fact that E17 has made it’s desgin decisions completely independent of the developments ongoing within the xorg community and the new libraries(cairo /glitz /libpixman etc.) being developed at freedesktop.org. This has triggered some concerns for me personally, because I really would like to see a set of technologies become more widely adopted amongst all of the desktop environments and I sometimes feel discouraged when the talent pool is seemingly watered down by each and everyone doing their own damned thing. But then again Rasterman and co. are offering EFL to the entire development community-look this is what we got, this is what it can do, please consider using it in your quest for next-gen graphics.
From this vantage point I cannot fault Rasterman and co. for going the route they have gone. In fact I have always wondered how X would be if that had been Rastermans project the entire time
The funny thing is E17 can do *today*, in it’s current pre-alpha state, what gtk+/cairo/glitz/Xegl or Qt/arthur promises to do in 1-2 years-and all this without a fundamental re-architecting of the entire X platform. I suspect E17 will be released sometime in the next 12-18 months (Rasterman feel free to suprise and release it sooner ! 
) And I honestly hope that the other wm/dm developers make liberal use of the painstaking hardwork that went into creating the EFL. They would be foolish not to do so.
Those are the numbers. I didn’t doctor them or lie. It’s what I got. If you don’t think them correct – please point out the errors in my testing. Also please READ everything I wrote – not just the numbers. The tool to test and my test method is explained there – with the source. Do some tests yourself. Yes some of them are very surprising. I would not have expected Fluxbox to be where it is – and in fact it has been fixed in the latest version. I only tested a particular set of things a WM does – but I am a big believer in benchmarks and real numbers not just what people think. People are subjective. Benchmarks (if done right) are not.
I tried to be as fair as I could. These are just the results I got – verbatim. They are not meant to be a “all wm’s suck” thing. You have to weigh up that this is testing 1 particular thing, and it doesn’t account for WM usability, stability, looks, features, etc. I was doing 1 thing. seeing if we haven’t screwed up E17’s code too badly during development. So far we haven’t. It’s in the same ballpark as the higher or mid end of most other WM’s.
I mean, is that really so important how long does it takes to open 1000 windows ?
I guess the time my WM takes to open a window is 0.00001% of the time i’m in front of my workstation…
So, does it really matters ?
1. If you read the page – you will see it was done for my benefit as a developer to see if the code isn’t too shabby. The point wasn’t to go “hey other wm’s suck”
Read what I wrote there explicitly to avoid people thinking that’s what this is. It’s about getting a ballpark set of objective benchmark numbers on something I can ACTUALLY benchmark easily. The problem is people dont pay attention to performance today – why is it your 3.0Ghz machine doesn’t feel any faster than a P100 did 10 years ago? One of the reasons is lack of performance analysis and attention to such details. The benchmark is limited – agreed. I did say that 
But take the information WITHIN the context intended 
.
2. It does matter. If it takes 10 seconds – it’s still a small fraction of the time you spend in front of your computer per day – but having to WAIT 10 EXTRA seconds (a very extreme example) for a window to come up will be bad. Also what about slower machines (p200?) these tests were on a fast machine – it’s the relative results than count, not absolute. The faster a window pops up the “snappier” a UI feels. It feels more responsive and feels better to the user. Even 0.5 seconds extra would be too much overhead.
Rasterman, the lead Enlightenment developer, benchmarks windowmanagers and finds his comes out on top.. this reminds me an awful lot of Namesys’ mostly bogus benchmarks on Reiser4.
Get back to me when some unbiased 3rd party has a result, then I’ll consider it valid, also what’s the feature comparison on this WM’s?
i always thought xfce was quite nippy – they certainly sell it that way. i’m surprised!
with all your talent Lovechild don’t you have anything better to do than troll….
Stop whinning and do yourself the benchmarks.
You have the testing tools and the WM to do it.
I can’t wait to install dr17 on Ubuntu Hoary.
You can apt-get Enlightenment DR17 by adding this line to your sources.list:
deb http://soulmachine.net/debian unstable/
When will we see a DR17 release? I’m watching the CVS and theres still a lot of bugs, and I would like to use a stable DR17 in all its glory.
I’m not a techie, so can’t judge the way tests were run and can’t point a better one. But looking at the results, it seems the tests don’t quite reflect the actual speed of WM’s. I mean, for any average user, fluxbox or xfce are faster than gnome or kde. If only because they require less memory.
Also for anyone that has used Gnome and KDE on modern hardware, it’s obvious they’re similar in performance, with KDE being slightly faster.
The results don’t match with users appreciations, so something must be wrong. I mean the tests are probably correctly done and absolutely fair. Also as limited as the author points since they just test 1 thing WM’s do. But it seems that that 1 thing is not representative of what we all call speed when we use a WM.
In the tests you can see several instances of E17, and not all of them are on the top. If we try to be fair, shouldn’t we compare E17 (CVS, default) to the other window managers? Or maybe even better, install E17 from debs (the soulmachine.net binaries) just like the rest of the competitors?
As far as the test method can be considered objective, you can see that, for example, also GNOME performs pretty well actually. But also I’m a bit surprised to find XFCE4 and Fluxbox near the bottom. In normal daily usage both Fluxbox and XFCE4 certainly feel quite fast indeed.
Somebody should make some broader tests and also tools for testing WM/DE performance. It could be quite useful for WM/DE projects and coders too.
Yeah, interesting. It would be even better to test scenarios closer to real work loads.
We are looking at this for Xfwm and it seems that things are optimized for low memory and the speed is very good when a low number of windows is present and then drops off rapidly.
Interesting none the less…
I am shocked at the number of people who can somehow type sentences (though a lot of the time nonsensical) but are not able to read the article or the comments before typing these sentences. One of those mysteries of the universe I guess.
Having said that — I can’t wait for e17, great job raster. Though I do feel sorry for you having to respond and listen to all these trolls, people who can’t read nor understand the benefit of testing their code with benchmarks
.
Ignore the trolls – there are people that appreciate what you’re trying to do with E17.
Talking about context. It would be nice to see more details about the benchmark.
Running the test om Metacity gave me about 30 win/sec. After removing some overhead things (eg. wnck stuff like window list and deskapplet in gnome; xscreensaver) and swiched theme from Bluecurve to Atlanta gave me about 65-67 win/sec on a athlon 2500+ machine with a nvidia 5200 fx card. As a Fedora user I’m not familiar with the default Debian packages and how they are configured. So a bit more details could then be nice.
Yes – the tests were very limited, but they are testing one of the largest involvements a WM has with apps on a system. I hope over time to have a much bettre test suite that tests much more and more in depth – as far as WM’s go. A lot of the things that happen on your desktop are not controleld by a WM at all. An app draws its own window contents – the WM isn’t involved. That’s more often a Toolkit.
My AIM is to test the WM and that alone, not every app with a DE and toolkits
But the test suite is nowhere near large enough to cover it all yet. It was something I quickly put together. Maybe later I will make something that creates a weighted average single benchmark result for a WM for its WM operations. That will come in time. I have made the benchmark tool public domain to invite any WM authors to put in tests they feel are good for helping improve the performance of their WM.
No serious.
Gnome may be faster than fluxbox possibly because of its session manager which flux does not have. And, no, I use flux.
The thing is, none of this matters. You can post benchmarks that show the CVS E17 is a hundred times faster than anything else but still nobody would care. The only thing that matters is an actual RELEASE of E17. Even if it isn’t half as fast as in the benchmarks, if you can make a build that is good enough that you dare to declare production ready, people would actually use it. Otherwise nobody will care. You’ll just keep chasing perfect code forever and 2 years from now E17 will still be in CVS. You know it to be true: the only thing that matters is a true RELEASE, benchmarks are worthless.
Benchmarks DO matter. If we releast E17 tomorrow and it takes 3 minutes to show a window, uses 18Gb of RAM, takes 3 Hrs to start and crashes after running 2 programs – it’ds a pointless thing to release. Release NOT everything
OK – so we release E17 and its slower, less features, etc. etc. than its predecessor – thats a pointless downgrade for most users. why release a DOWNGRADE? 
There is more to software than releases. And unfortunatelty benchmarks DO matter – they seem to have mattered to someone (other than me) enough to post an article about it. Enough peolpe have commented positiviely to show it seems to matter. I now have had responses from a few WM developers as to the “we made mistakes but have fixed them in the latest version and its faster” or “we think the tests can be improved” etc. 
They DO matter. They are already bearing positive results. There’s nothing like a bit of healthy, freindly competition between WM dev’s to improve the overall experience for users by having them optimise. There is more to software than the next version and a longer feature list. 
If this is the case, why so many “experts” tell Gnome is dog slow and KDE is swift?
Carsten
why is tested a so old release of kde?
KDE 3.3.2 and know there is KDE 3.4.1
every release of kde is faster…..
Read the article.
This has nothing to do with “speed” perceived by the user. Unless you open 10.000 new windows in 2 seconds, of course.
no – it means that gnome when setup as per debian defaults (the version given) has a faster window manager when it comes to handling a new window appearing in 2 majorly different circumstances. it is a specific test, not an overall benchmark of an entire desktop environment. it is testing specific things a window manager does – and window managers do a few very specific things.
Wondering if you had any target release date for E17? or even any guestimate.
Hi
I just checkout e17 and compiled it like described here:
http://www.robertgiebel.de/e17.php
Later I ran the wm_torture throughput test:
KDE 3.4.0 (pre packages from alioth for Debian) -> ~30 Wins/sec
200 Windows will pop up one by one and then close again one by one.
E -> ~60 Wins/Sec, but no windows will pop up. I am wondering why this is.
I ran the throughput test >5 times on each WM.
This is on an Athlon XP 2000+ (1666 Mhz), 512 MB, and Geforce 2 GTS Pro, under Debian Unstable(which comes with XFree 4.3).
If Rasterman’s results are correct, which I belive, than it’s time for me to spend some money and get a new machine.
Regards
paines
PS: If anyone finds out how to configure E’s menu and keyboard shortcuts, please drop me a line. Haven’t found it yet.
There’s no release date set, but feel free to grab our “timed releases” from http://enlightenment.freedesktop.org (those are timed snapshots from cvs when we feel we have a stable state of cvs)
Why is everyone making such a fuss about the lack of a “release” for E17?
It’s not difficult to compile from CVS (at least if you have Portage to do it for you…) or there are a number of snapshots floating about. Anyone that’s going to use a piece of software that is crucial to their system yet still in heavy development should be capable of dealing with the effort required to install it as-is – if not, why bother? It does take a little effort to use currently, so the install doesn’t need to be painless.
Slapping a 1.0 on the end of some tarballs won’t make it any better. However the current CVS version is quite adequate for normal usage – in fact I’d go so far as to say it’s better than any alternative I can think of. It’s crashed a couple of times recently, yes, but only when I’ve done things like run xcompmgr – which is quite capable of crashing _anything_ 😀
No Twm?
gnome > kde is terms of speed
yea if you saay so…..
it has been rewrote from scratch a couple time i think, not sure how that counts as a hack
ok, thanks for you constructive comments, i learned a few things and maybe i gonna use enlightenment – it seems to be quite fast.
>every release of kde is faster…..
Yes, 3.3 is faster than 3.4 and 3.4 is faster than 3.3 which means the speed difference is zero.
I’ve been using both GNOME and KDE and I must say that GTK apps work slightly slower in KDE (on my system, WAY slower) because all the GTK libs have to be loaded in addition to QT. I even think they use different fontlibs and anti-aliasing.
So, if you’re using mostly QT apps you’d better stay with KDE because KDE definetly works better with QT.
However, Gnome is much better when it comes to GTK.
Hey.
To me the map_throughput test is not very true to life and gives a false impression. My reasoning;
As far as I can tell you are just measuring the time for a very basic mapped window to get its first expose ( i.e become mapped ). This doesn’t take into account the main brunt of the work done is mapping a window is in the painting of window decorations which of course could happen *after* the app window has been exposed. Running the
test with something like metacity you never seem to ever
notice any window decorations even existing let alone being
painted.
The window is very very simplistic and unlike a real world application window which will have many extra properties set on it, from basic stuff like its title to more complicated stuff like EWMH props. Thus alot of processing the WM does before it maps the window will be avoided as there is nothing little process. As so much WM work is avoided, the test avoids stressing much of the work done on a new window mapping. Real world windows are very unlikely to be this simple.
It seems wierd to me that metacity is so much faster than something like fluxbox when I know metacity is doing much more work in creating its window decorations ( using Pango for instance – note, Im not saying thats a bad thing ).
Not trying to flame or troll here, just making an observation. Please correct me if Im wrong or have misunderstood.
This is basically funny…
As far as i see, Rasterman made this “benchmark” to see how well it was comparing to the others in this particular action… namely making new windows…
He never claimed to test real life behaviour. He was stressing his code… that’s all… don’t make a fuzz or a joke out of it… it’s useless!
If you would read the whole article on http://www.rasterman.com (and I did that several times) you would see that the word “benchmark” has never been mentioned. Only here on OSnews you suddenly call it a benchmark while it is not… it is a torture test… hence the name…
greetz,
ElAngelo
(keep up the nice work Rasterman
)
Thanks for the link. Ever since I watched the videos demonstrating E17 I was very impressed and looking forward to giving it a try.
[img]http://home-12.tiscali-business.nl/tpm33065/wm_test2.jpg%5B/img]
This is for the people who are wondering why oh why xfwm4 is scoring so bad… you can clearly see that up till 50 windows the speed is quite respectable… it only drops once the screen gets really full… This just means that the code in xfwm4 that handles the smart placement of the windows is getting into trouble if the screen gets overcrowded… Unfortunately i can not really proof this as there is no option to turn of the smart placement of windows… But you have a good chance…
For the end user it means that there’s no real problem.. the code only gets into problems once the screen is overcrowded (a normal user will not do this…). For the code it means that maybe there’s room for improvement… and that is what this torture test is all about…
gr,
ElAngelo
You may be correct in saying that he does not call them benchmarks on his site but a quote from one of Rastermanman’s post’s above indicates he does view them as benchmarks. See below.
” It’s about getting a ballpark set of objective benchmark numbers on something I can ACTUALLY benchmark easily.”
http://home-12.tiscali-business.nl/~tpm33065/screens/wm_test2.jpg
A “torture test” with empirical data … Ummmmm that _is_ a benchmark!
Benchmarks are all about the data that is collected while putting software through stress tests, normal usage tests, or idle tests… Even still, the stress level driving the benchmark is still only data…
The numbers are what matter.
“The problem is people dont pay attention to performance today – why is it your 3.0Ghz machine doesn’t feel any faster than a P100 did 10 years ago?”
i wondered if I was one of the only people who feel this way! Heck I dont think computers have technically “speeded” up very much at all, and by the time you load the memory hog software they seem slower than ever…. Of course, I still think one of the biggest “performance” factors of a processor is onboard cache…but anyway I am rambling…
Heck, why does the internet nowadays (dialup) seem slower than the “internet” of 600baud fame? Shove more crap down the pipe and it seems just as bad. I try to convince people that dialup could be more than speedy enough for everyone if it was rid of spam, flash, huge graphics, file sharing, etc…. they just look at me like i am a nut….
oh wait, i am
with all this work done I was wondering where the bulk of the remaining effort it? what still needsto be done? I haven’t read the source but I have seen the videos and I keep wondering what keeps the WM from being a 1.0 ? Just some stability issues like menioned in the article?
Looooove enlightenment, and now using e17 exclusively (ever since edge flip was added a few months ago)
I agree with what others saying – if you want e17, why wait for the “release”?
Why not just get it now?
http://get-e.org/
It is perfectly usable, lots of fun, and looks pretty.
o(^_^)o
On the other hand, if you wait for the “release”, you could be waiting for ages – the e team is full of new ideas. And I don’t see any predetermined “roadmap” of features that have to be implemented for e17 to be considered complete.
/(T-T)
There is a TODO list in cvs, but my guess is that there are lots of other cool goodies besides that to look forward to.
CaptainPinko,
You can see the main TODO list here:
http://cvs.sourceforge.net/viewcvs.py/enlightenment/e17/apps/e/TODO…
this is just about the wm not the DE
metacity is “supposedly” lean and fast, pretty sure that is why gnome chose it. But it certainly is not as cool as sawfish…..
I am impressed that sawfish is still rocking! I love sawfish! I think gnome should of kept sawfish….and from these number I would have to say that sawfish is not all that of a dog compared to metacity
IS there someone who has rebuild the packages from soulmachine to get them running un hoary, i cant install them because it complains about libc depency problems.
thx
What part of “for my own benefit to see if we have any bottleknecks” dont you understand.
These tests were not to prove to others that E17 is the fastest. It showed some interesting results and was published.
The Reiser 4 test was to show it was better, this test is for internal purpose first and foremost and published later.
try to not be so quick to judge next time
hey, what can i say…. should use the REAL debian, works on debian just fine thanks…
score one for debian
I compiled the most recent version from http://enlightenment.freedesktop.org/ and it’s VERY impressive. It’s all very smooth, everything scales/moves smoothly. Wiggling windows or moving through the menus (which have a neat animated effect when you mouse over) brings the CPU load to about 35% on my 2Ghz P4.
“Normal” use, like moving/activating windows, etc hovers around 10%. That blows my mind considering all the stuff that it’s doing in the background.. I’d like some way to tell if this is GL accelerated or not.. i didn’t do anything to enable it but this would be *twice* as impressive if it were all done in software.
It’s not really usable as it is though — There’s no way that i can see to edit the menu, or the “dock”, for example, and minimized windows “disappear” until you retrieve them using a nested menu. Seems very promising though..
Hahaha! Where are the GNOME/GTK/Metacity is slow trolls?
> why is it your 3.0Ghz machine doesn’t feel any faster than a P100 did 10 years ago? One of the reasons is lack of performance analysis and attention to such details.
I have only one thing say : you are a GREAT developer. I hope there are others great developers in the OSS world who can understand what you wrote and act accordingly. Without it, OSS will NEVER meet proprietary softwares quality because they require cluster of Cray computer to lauch a clock applet. Keep on the good work Raster !
What are you blithering about? All kinds of OSS projects are well optimized, and all kinds of proprietary projects (Easy CD Creator, Sony’s burn program, Acrobat, WMP, etc.) have speed issues because they either: Do stupid uneccessary things or they just don’t know how to get past the prototyping stage before their deadlines.
Just because many little KDE programs are ungodly slow doesn’t mean all OSS software is the same way. Many programs take efficiency too far like Dillo (awesome browser if you use a P100, bad if you like ssl).
Did you even read the article? Probably a third of those window managers keep up with e17…. None keep up with e17 with no modules and smart placement, DUH.
Great article though. E has always been fast and innovative. Keep up the great work rasterman. And please don’t force broken down GL hacks onto us; although working GL would be awesome.
I upgraded to kde 3.4 today, from mandriva 2005le and its version of kde 3.3.
I must say, I am very impressed with the speed increments. KDE feels altogether more snappy at doing everything.
I know KDE developers have been spending time on optimisations on the last few version, but 3.4 is excellent.
Well done
You are correct and incorrect in this assessment.
You are correct that this does not take into consideration the time necessary to draw the borders. This is important because that is the point when the window can be completely managed and used. That is not what is being measured in this case (it’s also much more difficult to measure in a WM independant way as there is no “FinishedDrawing” X event).
By testing when the window receives it’s first expose, you are testing the time until the window manager allows the application to begin interacting with the user. This is important to measure for two reasons:
1. the application output is the important part;
2. the application usually has to draw a larger area.
The user is using the window manager to interact with their applications, not just the window manager, so getting the application data to the user as quickly as possible is important.
The drawing of the borders is usually a very small percentage of the pixels needing to be rendered, take a window of 640×480 for example. If the window manager has a top border of 20 pixels in height, bottom border of 10 pixels and side borders of 5 pixels (these are fairly large borders). The window manager only has to push (640*20)+(480*(5+5))+(640*10) = 2400 pixels. The application now has (640-20-10)*(480-5-5) = 286700 pixels to render. These numbers are a high end, as they assume the application and window border are pixmap/image based. Based on this theory, the window manager should finish drawing before the application does as long as it uses reasonable rendering methods, so pushing the Expose event to the client window as quickly as possible can help them complete their drawing phases closer to the same time.
the absence of blackbox?
1. why did he compare his latest E with old versions of other WMs (KDE 3.3.2 is old, xfce 4.0.6 is old)
2. why does he list KDE and KWin, and why does he list XFCE and xfwm4…
Sure its important to get the app to the user ASAP, others may consider it just as important to have decoration windows painted before mapping ( to avoid annoying flicker ). Different WM’s will have different prioritys concerning this, my point being this makes up for difference in results.
Also much more that just firing pixels happens when a decorations are created/shown, glyphs will need to be processed, widgets possibly created ( for window controls ) and perhaps even some window shaping. It all adds up.
Because those were released and late in their stable cycle, so they should be as optimized as they’ll get from their current maintainers.
I like what I saw with the test results, and found it hard to beleive that fluxbox and openbox ranked lower than expected considering these are considered light WM’s. I have one version of enlightenment installed on my 233mhz/96MB laptop, and the visuals are stunning. Its not the latest release, that requires 3d and a few others, but probably the version before that. Nice and snappy, some animations. I couldn’t believe my eyes.
All in all enlightment is awesome and I appreciate the hardwork being done by rasterman. In fact, if he was gay and I was gay, I’d probably go out with him. But we both know neither one of us is gay.
As for all you disrespecting the article, its testing for his purpsoses. He said take it with a grain of salt and its really testing a few specific things.
I installed some version of E on my FC2 box a few months ago but I just couldn’t get any WORK done with it. I can’t even get any work done with KDE because the keystrokes aren’t what I’m used to in Gnome. I won’t put KDE on the desktops at my work because the keystrokes aren’t like the windows keystrokes. The multiple desktops v. multiple workspaces in E is even more confusing. E is more like a pretty gizmo rather than a work environment in, IMO. I’d like to see some of those transparency enhancements in Gnome, but I can’t get any work done unless I’ve got my alt-tab, or a quick way to map alt-tab.
Not every goddamn thing is directly related to how you percieve desktop performance. That’s an incredibly arrogant and self-centered way of looking at things. Raster is benchmarking E17 doing the operations a window manager does — manipulating windows. Whether it has a direct impact on you personally is quite irrelevant. Besides, if these sorts of benchmarks were never done, how would you know where the bottlenecks were?
E17 might be the fastest thing to hit the desktop, it might be full of cool new ideas and cool tricks, but it is VAPOURWARE. Raster has been desperate to keep some of the spotlight on him and his baby, but people are simply bored of a project that has failed to deliver.
This year will come and go, there will be no end user E17 release
Next year will be the same…
..and the yeeat after that…
..and the year after that.
Too few runs –minimum 30 independent runs is very recommended. What about median, minimum and maximum?
“Best of 3” What?!?
Every time someone questions whether these benchmarks matter at all, you go on to talk about windows taking “ten seconds” or “three minutes.” How about when it takes an unnoticeable amount of time?
“why is it your 3.0Ghz machine doesn’t feel any faster than a P100 did 10 years ago?”
It does. A lot faster. People who say this have, generally speaking, not tried using a P100 for a long time, and are falling victim to susceptible memories. Go pull one out of a skip, try it, and you’ll see that the old saw that ‘modern systems don’t feel any faster because programmers waste all the resources’ isn’t really true. They _do_ feel faster.
Where is this video I have hear of?
Thnx
“It does. A lot faster. People who say this have, generally speaking, not tried using a P100 for a long time, and are falling victim to susceptible memories.”
Bah. Compare your 3 GHz computer running KDE/GNOME/XP/OSX to an old Amiga running AmigaOS. Glad to see a benchmark like this btw perhaps those who are complaining about the limited test target/results are able to actually improve the test utility (its open source).
I tried it and was not too impressed. There is a lot of glitz, but I actually think all the fizz gets in the way. The glistening window bars are annoying (IMO. However I think with a few tweaks I could really like this desktop. I wonder if there is a way to skin various applications so they feel more like a cohesive DE.
All you see with E17 right now “out of the box” is software rendered only. no hardware acceleration. Theer are hidden switches in the code to enable GL for parts of your display. I have enabled it before for my desktyop bg – but the quality of GL’s down-scaling is… to be desired
Anyway – right now its all software because its stable, doesn’t rely on special drivers or graphics cards, and “just works”. 
Yes – we need to work on confiugration and usability – it’s on our TODO list – that’s why E17 isn’t released yet. You can configure these things, but the conifg is buried in your filing system right now or via IPC calls done by a command-line utility.
Obviously you are an end user that got disappointed with E17, and more so you are clearly a Troll, let me enlighten you a bit:
1) Enlightenement does use OpenGL, Evas (E drawing library) has an OpenGL accelerated path, i’m running e17 using OpenGL acceleration and don’t have any problem at all (except for funky borderless programs like xmms) and it rocks! BLAZING fast.
2) The dropshadows are NOT a hack, they are implementing using all the E17 infrastructure only, Composite dropshadows where a hack until got added to X.org mainline. Xgl started as hack and now is shaping up.
3) Even if you use OpenGL acceleration i don’t think it would help much unless you have a fast nvidia card and use the nvidia drivers. Otherwise Software rendering path is still faster, soo optimized that some code was added to X.Org for “Composite Dropshadows” from E17 as software fallback.
4) I’m using E17 on my old P133 thinkpad laptop, you know what? is faster than any other desktop, even most WMs and comes with extra goodies.
In resume, STFU unless you know what you are talking for sure.
Each test runs either 200 ro 1000 times in each run – the testing took a good 2 hrs to do them all as i logged in freshly for each test. best of 3 was me giving the wm a good chance to perform as the fastest results will be closest to the truth – the lower ones are more likely due to system entropy (background tasks using up processing power). doing 30 runs wasn’t going to happen. i’d spend an hour per wm at least to do that. as i said – it was mostly for my benefit to know where the bottlenecks are (and then fix them) and what the ballpark is like – you dont know if you are “done” with optimising unless you know where you stand compared to other software doing the same thing. if i think i’m done, but still am 1/100th of the speed of equivalent software i likely have a lot of optimising left to do and just don’t know how – maybe a big desing flaw. maybe i can justify it as i know why i am slower and it is for a good reason etc.
Actually – I remember timing the time it took to start netscape… 1.1 back on my p120 – it’s not dissimilar to starting firefox these days
about 5-10 seconds. (cold start).
I developed E0.1 – E 0.13 on a p120. I know what issues i was dealing with in code
If you don’t think them correct – please point out the errors in my testing.
Good test. Would be a little better if you used the newer XFCE4.2x. Add this line to sources.list and give XFCE a better chance. You might be suprised- I am.
deb http://www.os-works.com/debian testing main
I get where you are coming from with regards to usability speed of WM’s on nix. If E17 is what you are stating and with elegance too boot, I’m there. One of the things that keeps me pining for BeOS to make a comeback was the responsiveness of the UI. It really made computing a fun experience and turned a slouchy K6-400 Win2K computer into a speed demon. I could do things on that system which I still can’t do today on my WinXP/Arch Linux Dual AMD MP2000+ with 4x the memory.
Presently, todays OS’s are a fucking joke in usabiliity and performance. We throw $ into faster systems only to have all the computing horsepower gobbled up by pathetic code. If E17 can give to Nix what BeOS did for me then I would be inclined to stay with Linux but at the moment, although for me Linux is the better alternative, I am still waiting for a BeOS pheonix to rise from the ashes in the form of Zeta or Haiku.
Good luck Raster and keep up the effort as nix needs some tight coding and people with vision.
@rasterman
Why not make a beta release at least? Why fiddle with the code endlessly? I remember you going on about EVAS years ago, yet here we are, still no release. Like I said, proclaiming the superiority of EVAS and the other technologies behind E17 is rather pointless if nobody ever gets to use them-beyond a small community of developers.
Also, why is it the Luminocity tech demo can do what you have said is ‘impossible’ without major improvements to render and others parts of Xorg? Live
He was talking about the clipboard in KDE. E17 has no decent clipboard manager.