Linked by Hisham Mardam Bey on Thu 9th Jun 2005 07:23 UTC
Window Managers 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).
Order by: Score:
dusty 'puters
by fish on Thu 9th Jun 2005 07:36 UTC

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.

E rules!
by matte on Thu 9th Jun 2005 07:41 UTC

what can i say, E rules! i can't wait to get a stable E17 release ;) , nice work Raster and you other guy's.....

ALT + TAB, Copy and paste
by Kin on Thu 9th Jun 2005 07:45 UTC

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 is a hack
by Mexican on Thu 9th Jun 2005 07:46 UTC

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.

by Anonymous on Thu 9th Jun 2005 07:50 UTC

wow, i am really suprised that fluxbox is near the bottom!
anyone know why?


RE: ALT + TAB, Copy and paste
by Dogacan Guney on Thu 9th Jun 2005 07:50 UTC

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.

XFCE one of the slowest?
by Artem on Thu 9th Jun 2005 07:51 UTC

Now that's a surprise... In the first test it's way slower than kwin amd metacity! Weird...

Re: E is a hack
by Jon Door on Thu 9th Jun 2005 07:51 UTC
RE:E is a hack
by Dogacan Guney on Thu 9th Jun 2005 07:53 UTC

AFAIK, E(vas) can also draw on OpenGL, but more importantly it can also draw on cairo.

Sorry to spoil the fun
by L.Lunak on Thu 9th Jun 2005 07:57 UTC

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.

it doesnīt work
by Kin on Thu 9th Jun 2005 07:57 UTC

>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

by Andrea on Thu 9th Jun 2005 07:59 UTC

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 :/

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)

by Nikola Pizurica on Thu 9th Jun 2005 08:00 UTC

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.

by Andrea on Thu 9th Jun 2005 08:01 UTC

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.

by Anonymous on Thu 9th Jun 2005 08:02 UTC

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.

whats that chart about ?
by raver31 on Thu 9th Jun 2005 08:02 UTC

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

v RE: E is a hack
by Mr. Anderson on Thu 9th Jun 2005 08:02 UTC
by Rapsey on Thu 9th Jun 2005 08:07 UTC

Yeah great, but how about actualy releasing the damn thing?

v E is still a hack
by Mexican on Thu 9th Jun 2005 08:09 UTC
by Luk van den Borne on Thu 9th Jun 2005 08:10 UTC

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.

beautiful but ...
by mizu on Thu 9th Jun 2005 08:10 UTC

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...

Complaining about results
by Archangel on Thu 9th Jun 2005 08:15 UTC

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 :-P

by Luk van den Borne on Thu 9th Jun 2005 08:18 UTC

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.

by Anonymous on Thu 9th Jun 2005 08:18 UTC

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.

RE: E is a hack
by Raster on Thu 9th Jun 2005 08:18 UTC

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. ;)

DEs != WMs
by toto on Thu 9th Jun 2005 08:20 UTC

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.

RE: Mexican
by karl on Thu 9th Jun 2005 08:24 UTC

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 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.

RE: whats that chart about ?
by Raster on Thu 9th Jun 2005 08:29 UTC

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.

Hum... and so what ?
by Federico on Thu 9th Jun 2005 08:52 UTC

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 ?

RE: Hum... and so what ?
by Raster on Thu 9th Jun 2005 09:04 UTC

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.

Credible benchmarks
by Lovechild on Thu 9th Jun 2005 09:06 UTC

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?

xfce so bad?
by tech_user on Thu 9th Jun 2005 09:08 UTC

i always thought xfce was quite nippy - they certainly sell it that way. i'm surprised!

re: Lovechild
by karl on Thu 9th Jun 2005 09:23 UTC

with all your talent Lovechild don't you have anything better to do than troll....

RE:Credible benchmarks
by me on Thu 9th Jun 2005 09:25 UTC

Stop whinning and do yourself the benchmarks.

You have the testing tools and the WM to do it.

E17 for Debian/Ubuntu
by Metic on Thu 9th Jun 2005 09:27 UTC

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 unstable/

by Anonymous on Thu 9th Jun 2005 09:37 UTC

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.

Strange results
by Anonymous on Thu 9th Jun 2005 09:41 UTC

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.

WM performance
by Metic on Thu 9th Jun 2005 09:49 UTC

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 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.

Re: Strange results
by Jasper on Thu 9th Jun 2005 09:50 UTC

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...

Learn to read
by kungfooguru on Thu 9th Jun 2005 09:53 UTC

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 ;) .

by Norva on Thu 9th Jun 2005 10:01 UTC

Ignore the trolls - there are people that appreciate what you're trying to do with E17.

by Daniel on Thu 9th Jun 2005 10:06 UTC

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.

Re: Strange results (Jasper)
by Raster on Thu 9th Jun 2005 10:06 UTC

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.

not a troll
by Anonymous on Thu 9th Jun 2005 10:16 UTC

No serious. ;)

Gnome may be faster than fluxbox possibly because of its session manager which flux does not have. And, no, I use flux.

by Anonymous on Thu 9th Jun 2005 10:20 UTC

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.

RE: @Raster
by Raster on Thu 9th Jun 2005 10:31 UTC

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. ;)

Does that mean that Gnome is ~3 times faster than KDE?
by pica on Thu 9th Jun 2005 10:35 UTC

If this is the case, why so many "experts" tell Gnome is dog slow and KDE is swift?


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.....

Re: oes that mean that Gnome is ~3 times faster than KDE?
by Anonymous on Thu 9th Jun 2005 10:45 UTC

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. ;)

by Andrewg on Thu 9th Jun 2005 11:22 UTC

Wondering if you had any target release date for E17? or even any guestimate.

Rasterman's wm_torture
by paines on Thu 9th Jun 2005 11:26 UTC


I just checkout e17 and compiled it like described here:

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.


PS: If anyone finds out how to configure E's menu and keyboard shortcuts, please drop me a line. Haven't found it yet.

RE: @Raster (Andrewg)
by Hisham Mardam Bey on Thu 9th Jun 2005 11:29 UTC

There's no release date set, but feel free to grab our "timed releases" from (those are timed snapshots from cvs when we feel we have a stable state of cvs)

by Archangel on Thu 9th Jun 2005 11:29 UTC

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_ :-D

by Jeff Flowers on Thu 9th Jun 2005 11:33 UTC

No Twm? ;)

by none on Thu 9th Jun 2005 11:59 UTC

gnome > kde is terms of speed

e17 a hack
by joe on Thu 9th Jun 2005 12:13 UTC

yea if you saay so.....
it has been rewrote from scratch a couple time i think, not sure how that counts as a hack

thx, Rasterman
by Evert on Thu 9th Jun 2005 12:13 UTC

ok, thanks for you constructive comments, i learned a few things and maybe i gonna use enlightenment - it seems to be quite fast.

@Marc Collin
by Zlogic on Thu 9th Jun 2005 12:32 UTC

>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.

@raster test not real world ?
by mallum on Thu 9th Jun 2005 12:54 UTC


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

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.

v Re:E is a hack
by Anonymous on Thu 9th Jun 2005 12:54 UTC

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 (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...


(keep up the nice work Rasterman ;) )

@ Hisham Mardam Bey
by Andrewg on Thu 9th Jun 2005 13:08 UTC

Thanks for the link. Ever since I watched the videos demonstrating E17 I was very impressed and looking forward to giving it a try.

xfce scores
by ElAngelo on Thu 9th Jun 2005 13:16 UTC


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...


@ ElAngelo
by Andrewg on Thu 9th Jun 2005 13:17 UTC

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."

re: this is no benchmark... it's TORTURE test...
by Anonymous on Thu 9th Jun 2005 13:18 UTC

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.

by joe on Thu 9th Jun 2005 13:19 UTC

"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 ;)

whats left?
by CaptainPinko on Thu 9th Jun 2005 13:54 UTC

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?

yay for e17!
by david on Thu 9th Jun 2005 14:01 UTC

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?
It is perfectly usable, lots of fun, and looks pretty.

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.
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.

RE: what's left?
by david on Thu 9th Jun 2005 14:10 UTC

You can see the main TODO list here:

by joe on Thu 9th Jun 2005 14:24 UTC

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

ubuntu again
by debt on Thu 9th Jun 2005 14:26 UTC

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.


RE Credible benchmarks
by Anonymous on Thu 9th Jun 2005 14:56 UTC

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

ubuntu ubuntu ubuntu
by joe on Thu 9th Jun 2005 15:00 UTC

hey, what can i say.... should use the REAL debian, works on debian just fine thanks... ;) score one for debian

by Kirtis Bakalarczyk on Thu 9th Jun 2005 15:37 UTC

I compiled the most recent version from 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..

GNOME is slow!
by . on Thu 9th Jun 2005 15:51 UTC

Hahaha! Where are the GNOME/GTK/Metacity is slow trolls?

by BongoBong on Thu 9th Jun 2005 15:55 UTC

> 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 !

by Chris on Thu 9th Jun 2005 16:20 UTC

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.

by raver31 on Thu 9th Jun 2005 16:22 UTC

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

RE: @raster test not real world ?
by Anonymous on Thu 9th Jun 2005 16:32 UTC

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 640x480 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.

once again
by broken windows on Thu 9th Jun 2005 16:53 UTC

the absence of blackbox?

what i don't understand with this test...
by Mathias on Thu 9th Jun 2005 16:58 UTC

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...

RE: RE: @raster test not real world ?
by mallum on Thu 9th Jun 2005 17:12 UTC

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.

by Chris on Thu 9th Jun 2005 17:24 UTC

Because those were released and late in their stable cycle, so they should be as optimized as they'll get from their current maintainers.

Good results
by TaterSalad on Thu 9th Jun 2005 17:53 UTC

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.

mumble mumble E17 mumble whatever
by Jed Reynolds on Thu 9th Jun 2005 18:43 UTC

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.

by Rayiner Hashem on Thu 9th Jun 2005 18:47 UTC

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?

What is the point.
by The man who wasn't there on Thu 9th Jun 2005 18:52 UTC

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.

Bad setup test
by DS.c on Thu 9th Jun 2005 18:54 UTC

Too few runs --minimum 30 independent runs is very recommended. What about median, minimum and maximum?

"Best of 3" What?!?

by Anonymous on Thu 9th Jun 2005 19:00 UTC

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?

by AdamW on Thu 9th Jun 2005 19:33 UTC

"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.

by Jon on Thu 9th Jun 2005 20:14 UTC

Where is this video I have hear of?

@ AdamW
by Anonymous on Thu 9th Jun 2005 20:43 UTC

"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).

by dt on Thu 9th Jun 2005 21:16 UTC

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.

RE: E (Kirtis Bakalarczyk)
by Raster on Thu 9th Jun 2005 21:39 UTC

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.

RE: E is a hack
by Carlos Daniel Ruvalcaba Vlz on Thu 9th Jun 2005 21:45 UTC

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 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.

RE: Bad setup test (DS.c)
by Raster on Thu 9th Jun 2005 21:54 UTC

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.

RE: raster: (AdamW)
by Raster on Thu 9th Jun 2005 22:11 UTC

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 ;)

RE: raster
by poofyhairguy on Thu 9th Jun 2005 22:52 UTC

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 testing main

Re: Raster
by Piers on Thu 9th Jun 2005 23:09 UTC

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.


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

by Sepht on Thu 9th Jun 2005 23:23 UTC

He was talking about the clipboard in KDE. E17 has no decent clipboard manager.

by The man who wasn't there on Thu 9th Jun 2005 23:27 UTC

Oh and btw...

Rasterman has been bleating on about E17 for years, the story never changes though. Rasterman says everything else but whatever he is working on sucks. Stay tuned folk for Rasters upcoming inteview scheduled for 2010 when he will tell us all that E17 still rocks, but that it needs another rewrite before it can be released.

RE: So how about some kinfd of release.
by raster on Thu 9th Jun 2005 23:31 UTC

(it's linked to from the "get enlightenment" page on


but i am waiting till its more or less at the same state of usability as e16 in terms of features before releasing it and letting it out in the wild as a proclaimed release. we have limited resources - none of us get paid to work on this fulltime, unlike gnome and kde developers of which dozens do, for example. i dont want to release it then dissapoint users with fewer features than previous versions.

:) and it's not fiddling - evas is mostly stable - it's just waiting for e17 to get the 1.0.0 stamp on its forhead - a chunk of the EFL will be released as 1.0.0 when e17 comes out. i like to do things in big lumps all at once ;)

by The man who wasn't there on Thu 9th Jun 2005 23:49 UTC

There is a reason E lacks developers, because people don't want to work on a project that throws code out on a whim. KDE and Gnome are actually real projects, that release real software that real people use. e17 has become nothing more than Rastermans massive ego, it is easy to proclain your work to be the best when you fail to truly compete. Competing means making a release, instead of simply dining out on fanciful stories about how wonderful evas is.

2 Rasters?
by Sepht on Thu 9th Jun 2005 23:50 UTC

In the first few posts Raster posts from

last few are from

I'm betting that the latest guy is a fake, seeing as Raster 1) Capitalizes his name 2) Uses proper capitalization and grammer.

Speed vs agnosticism
by Mats Johannesson on Fri 10th Jun 2005 00:00 UTC

Rasterman has always honked the speed horn, but what use is speed in a software that can't be compiled on your platform. Eg Enlightenment 0.16 which depends on another raster product, the imlib[1,2] which contains 32 bit assembler.

On a pure x86_64 platform that's just... byebye E.

Has E 0.17 resorted to such 'speed hacks' in its dependency libraries as well (some 15 of them, or such)? I won't even try the compile myself. If I encountered 32 bit assembler I'd probably fly downt to Japan and punch some raster nose!

Compiling packages here I've only bumped into this issue twice for now. E joins hands with a shitty thing called unzip-5.52 (when doing the shared library).

Mats Johannesson

RE: 2 Rasters?
by raster on Fri 10th Jun 2005 00:13 UTC

It's still me - One is from work - the other from home - thus different computers, different borswer configs, different isp... different domain...

RE: Speed vs agnosticism
by raster on Fri 10th Jun 2005 00:18 UTC

Eh? yes - theres mmx optimised asembly - 90%+ of users have an x86 32bit cpu. it has FAST C CODe too. why do u think it works on sparc? ppc? alpha? mips? arm? the x86 detection thinks u are an x86 because the auto-detect on linux woudl check /proc/cpuinfo as a guess to build it - if you compile amd64 code this fails as they changed register names. that detection has been fixed in the latest imlib2 1.2.x snaps. you can --disable the mmx compiling and you get highly optimised C versiosn that still beat almost anything out there. i write the C versions BEFORE i write mmx optimised ones. check the code and configure options before passing judgement. it is NOT x86 specific only. it has x86 specific optimisations IF your cpu is x86 - which may not be YOU but is 90+% of people using the stuff. you can compile it - you just need to manually disable the feature as the auto-detect gets it wron as amd64 came out long AFTER the autodetect stuff in the configure scritp was written - it's much older than amd64.

RE: Speed vs agnosticism
by Mats Johannesson on Fri 10th Jun 2005 00:32 UTC

I blowed off some steam ;-) But you must admit that it does _not_ look good to be in companion with a "DOS" tool.

If imlib has cleaned up its detection mechanism, then by jove make it available as a stable release!

You see the trend? Releases MATTER.

I do enough of ./configure --help|less in normal cases. But those are for totally unknown programs/switches. Turning off mmx to make something compile is nothing that comes to my mind in a second. I just shrug and move along (fluxbox compiled without hassle)

Mats Johannesson

RE: Speed vs agnosticism
by raster on Fri 10th Jun 2005 01:00 UTC


there u go - imlib2 its a buildable versioned cvs snapshot. it shoudl work out of the box. imlib2 is not dos-like or competing with dos stuff - the problem is i have no amd64 machines - i dont see these problems until people bring complaints to me and fixes as i dont know what causes them until i am given enough information - or patches. ;)

RE @ couple of people
by fish on Fri 10th Jun 2005 01:01 UTC

"this reminds me an awful lot of Namesys' mostly bogus benchmarks on Reiser4.
why is tested a so old release of kde?"

So what is the fastest file system?

"KDE 3.3.2 and know there is KDE 3.4.1

every release of kde is faster....."

I actually find kde 3.3.2 to be faster, but thats just my opinion.

Nontheless I find I get work done more efficiently with Gnome apps vs KDE apps. Gnome apps tend to be pretty dumbed down.

Take Goobox for instance, a complete moron could rip and encode a cd with Goobox.
Wasting ten minutes learning how to use each new application just takes away from the real reason why I use a computer.

To be efficient.

So in the long run I find Gnome to be more efficient as DE which makes up for its WM slowness.

I hope Enlightenment's team can understand this when they do release dr17/e17?

if you made some alpha/beta releases. This is how you get widespread testing a feedback, but then that would be something a serious project would do, probably not your thing.

Re: you might get more feedback...
by MechR on Fri 10th Jun 2005 01:14 UTC

"if you made some alpha/beta releases. This is how you get widespread testing a feedback, but then that would be something a serious project would do, probably not your thing."

Sheesh, you coulda made a decent point there, but then you had to add that rude dig at the end -_-'

RE: Speed vs agnosticism
by Mats Johannesson on Fri 10th Jun 2005 01:28 UTC

"there u go - imlib2"

No, I meant a _buildable_ package. Contact me if you want a guinea pig on a no multilib amd64 system: lista1 at telia dot com.

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/freetype2 -I/usr/X11R6/include -I. -I../.. -I../.. -O2 -march=athlon64 -ffast-math -pipe -c ximage.c -fPIC -DPIC -o .libs/ximage.o
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/freetype2 -I/usr/X11R6/include -I. -I../.. -I../.. -O2 -march=athlon64 -ffast-math -pipe -c ximage.c -o ximage.o >/dev/null 2>&1
make[3]: *** No rule to make target `amd64_blend.S', needed by `amd64_blend.lo'. Stop.
make[3]: Leaving directory `/home/2blfs/05graphics-libs1/8imlib2-cantinstall-is-32bitasm/imlib2-1 .2.0.008/src/lib'

Mats Johannesson

RE: The girl who wasn't there
by Brian on Fri 10th Jun 2005 02:34 UTC

You seem to bear a personal grudge against Raster. I'd be really interested to know how his writing code could offend you so much. Did he shoot your dog? Seriously, why all the hostility? And I'd like you to point out where his ego comes into play, as he's been nothing but polite in the face of a barrage of uninformed trolling from yourself and others. Personally, I wouldn't stand for your brand of hate-inspired trolling. I fail to see what you (or anybody, for that matter) have to gain from bashing a project.

As for other "interested parties", I believe Raster clearly stated why he's not releasing e17 yet. It's not ready. That's evident from those individuals who downloaded the alpha and then complained about the lack of configuration tools and intuitiveness. I won't lecture them on the incredible idiocy of these complaints in regards to alpha-state software, but needless to say, that's precisely why it's alpha. The project is caught between a rock and a hard place, as everybody is clamoring for a release, yet at the same time demanding perfection in usability.

Now, with respect to the complaints of "too much eye-candy and not enough functionality", this is because e17 at the moment is a technology preview. It's intended to show off what it *can* do, not what it will look like as a final product. Don't like the shimmering borders? Neither do most people, but it's a demonstration of a capability that might come in handy for themers at a later date and proof of concept. Instead of complaining, change the theme. A few very tasteful ones are available from:
Check it out.

I, for one, admire how hard and long Raster and the other e devs have worked to make this possible. The toughest 90% is done. The framework is in place. Now all that is really needed is bug squashing and more community involvement.

by Finalzone on Fri 10th Jun 2005 03:29 UTC

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.
I have a P200 with only 96MB RAM. If that is statement is true, I am glad to wait for the incoming FC4 so I can install E17 after doing minimal install.

I have tried E17 on FC3. What is lacking are the menu from Gnome or KDE. I heard these options is added so I will try out later.

by gnu on Fri 10th Jun 2005 04:50 UTC
Re: The man who wasn't there
by deepspace on Fri 10th Jun 2005 11:16 UTC

Give Rasterman some credit. What he did is great. Throwing away code is often a good thing! You don't wat te start hating the old reliks that you ones made. And with this project, you can do that much easyer that with Gnome or KDE. Rasterman is giving his best to make the most out of it. He deserves the attention and support!

Sure, not everything is great, but what do you expect? He is no God ;) Sure, a real release might take some time, but when it comes, it will be very solid, and well thought of.

I for one, will try it ones again soon ;) Always nice to try other stuff!

by Solskogen on Fri 10th Jun 2005 13:18 UTC

For how long has e17 been developed? is it downloadable yet? from cvs? with a install routine longer than gentoo?
If I recall correctly Userfriendly made a strip making fun of Duke Nukem Forever and HL2 coming in the same pack. Now its time to make fun of Duke Nukem and e17.

RE: When
by david on Fri 10th Jun 2005 14:44 UTC

People already do compare duke nukem and e17. It's not funny anymore though, I've seen that joke at least 10 times already :-)
(see slashdot for examples - maybe OSNews has some too)

Yes, you can get e17 from CVS, but there are also snapshots available. As mentioned already, the snapshots are more likely to be stable than CVS. The snapshots aren't that out of date either.

Installing e17 currently involves compiling and installing six libraries from the EFL (Enlightenment Foundation Libraries) and then e17 itself.

I think it would probably take about 20 minutes for me to build - but the first time it might take longer as you may find you need to install other build dependencies first.

If you have a hour or so free, visit, and give it a try. E17 is good already, and it can only get cooler!

RE: When
by david on Fri 10th Jun 2005 14:52 UTC

Speaking of snapshots, there are fresh ones from today there at right now... have fun!

RE: Sorry to spoil the fun
by Jon Dowland on Fri 10th Jun 2005 15:20 UTC

"First, this is only about showing a window. How many new windows do you get if you launch a new application? One?"

Wrong: Hundreds. There's a new X "Window" for virtually every drawing primitive in a toolkit : each button, scrollbar, menu drop-down, etc.

stop wasting our time
by jaekman on Fri 10th Jun 2005 15:44 UTC

no matter what, evas still only can render inside a window! there is no compositing at the window level and there never will be. so, stop wasting my time with these pointless E17 status reports, because i dont care about how cool it is to render custom widgets inside of windows. its a dead end technology unless someone creates an x-server for evas allowing for cross-window compositing, which would still be way slower than something like LUMINOCITY.

A turd by any other name....
by The man who wasn't there on Sat 11th Jun 2005 03:20 UTC


Don't bother Rasterman with anything so trivial as the truth. He exists in a world of make believe, where E17 has a future, and EVAS is the best thing since sliced bread. Frankly I pity the man, years spent working on a dead-end project. Nobody is going to give E a second thought in 12 months time, when KDE and Gnome and fully GL accelerated

Man, come on! this is not /. please keep your trolling for it.

Evas is great, E17 gots lots of cool tech on it. Don't like it? don't use it, simple.

Please save the space, as OSNews still donse't have a way to filter continued trolling as yours.

Oh my, so many idiots...
by xcomp on Mon 13th Jun 2005 16:00 UTC

..I don't know where to start. Some of these fools have not written five lines of code in their lives, have no clue as to what exactly this project is about, but their mouths are spitting out crap faster than a Russian submachine gun. I'd smack you over the head with a clue-by-four, but instead I'll hope maybe you'll have enough brains to head over to the Enlightenment web site and actually READ for yourself and find out what this project is about.