Slashdot Mirror
Rasterman Responds To Seth And Havoc
An anonymous reader writes "Rasterman, of Enlightenment fame, has responded to Seth Nickell and Havoc Pennington's blog entries, which were in reference to this previous article. about Next gen X rendering. Raster says: 'Well it seems the XDevConf has produced some interesting blogs and discussion. I'm a bit sad I was not able to attend (no funding at all), as there seems to have begin a lot of discussion and moves in directions we in Enlightenment land have been going for years, and are likely far ahead in. I guess this means we haven't been able to share our experience in this. Maybe next year. Anyway the point is that this has started up some musings from Seth Nickell and Havoc Pennington related to this. This is great - finally people are beginning to take seriously what the Enlightenment crowd have been talking about for years.'" (Note: the previous post was about Nickell's post, not the other way around.)
http://www.osnews.com/comment.php?news_id=9791
has alot of responces from raster on this subject so its worth a read and there also seems to be some progress on the whole debate
Click on the link to Rasterman's web site (over the text "Rasterman"). It's on his main web page.
If X is slow its more then likely your setup and not X its self. Don't belive me? Run Fluxbox instead of Gnome or KDE and see how responsive it becomes. Now run a Gnome or KDE that was compiled for a more sane arch, ie i686 instead of i386 and see how much more responsive it becomes. Now run RDC and XDMCP side by side and see how well the Xprotocol works. X is not slow. I run KDE 3.4b2 on a dual p2 with 768 mb ram with a lot of eye candy turned on, I run an XDMCP session to a Sun box running Solaris 8 and right next to it, XP on a Sempron 2500+. I see no UI responsiveness difference until the systems become busy, and then its often XP that first slows.
"I use a Mac because I'm just better than you are."
Tuesday, 22 February 2005
:) He mentions "A sophisticated drawing layer" (read his blog for the full text). We have that - Evas. it can accelerate via OpenGL, it's got a FAST software renderer. It can render to the Linux Framebuffer. It can render to memory. It can render using DirectFB. It can render using *GASP* ... Cairo! It can display in Qtopia. We can add new engines for new targets with little effort. Evas scales down to rendering at usable speeds on embedded devices (100-600Mhz ARM CPU's, limited RAM etc.). He discusses a toolkit that aggressively takes advantage of this - we have been working on EWL and Edje. Edje is a lower layer theme/layout system, with EWL being a full widget set on top of this, giving you whiz-bang themes with widget layout built on top of an Evas canvas with everything punting down to the rendering layer at the bottom there. We are doing our own Window Manager - and the day Xrender stops sucking, we will add compositing to it too - re-using all the layers we already have to do this. We have a low level acceleration mechanism (OpenGL) but its too unstable for use IMHO. This is a problem that needs fixing and is something that needs to be addressed.
:) Hundreds of snowflakes driving down the screen... E17 has a toy module for just this... and flames to burn them up as they hit the bottom of the screen. All with glorious alpha blending. He speaks of animated background desktops with things like grass blowing in the breeze - We do that already in E17. The desktop BG is an Edje file - and thus is capable of all the animation and effects Edje and Evas offer. In fact take a look at the following 2 video files (they are jerky because xvidcap is jerky and thats just how it is - in real life they are smooth as a babies bottom - you just have to see these things "live" to believe it. Also note - this has NO hardware acceleration. I am hoping one day to have acceleration available that is good enough for production use).
Enlightenment the experimental toolkit
Well it seems the XDevConf has produced some interesting blogs and discussion. I'm a bit sad I was not able to attend (no funding at all), as there seems to have begin a lot of discussion and moves in directions we in Enlightenment land have been going for years, and are likely far ahead in. I guess this means we haven't been able to share our experience in this. Maybe next year. Anyway the point is that this has started up some musings from Seth Nickell and Havoc Pennington related to this. This is great - finally people are beginning to take seriously what the Enlightenment crowd have been talking about for years.
What I'll go into is some of the things Seth and Havoc talk about that we have already done and are well under way or very mature. Things we have advocated for years and have already solved - quite optimally. Our designs are forward-looking and just WAITING for drivers to catch up and stop "sucking". I could write essays about the many ways to address this issue alone (XRender), but I won't go there this time. I've been there before.
First let me talk about Seth's blog. He discusses "Next-Generation Rendering For the Free Desktop". This is great. this is just what we need... oh wait. it's just what we've been DOING for years!
Now he goes on to say what this will enable: "Toolkit themes that draw with layer blending effects" - Done. EWL, Evas, Edje. "Indiana Jones buttons that puff out smoothly and animated clouds of smoke when you click on them". OK - we don't have the smoke - but we have all the animation, glinting in the light, fading, glowing, sliding, etc. etc. etc. We have an entire engine devoted to just this (Edje), a theme description language, compiler, scripting engine, compressed theme format usable "live" without installation etc. He goes on to talk of "Alpha transparency whenever you want" - Done. Evas. Live window thumbnails - XRender has to improve something WICKED for this to be sane.
files/e17_movie-02.avi
files/e17_mov
the vids on his site are amazing! the theme he's got on there is ugly as sin, but seeing through that and looking at the tech behined the whole thing, and you see what the future could be.
all the nice effects that mac and longhorn will be doing next year could be tied into xorg/gnome within 6 months.
all rasters stuff is on freedesktop.org, so it's all open.
in a perfect world, someone like novell would hire raster to work with the gnome xorg devs. get evas+cairo into the desktop stack, and have gnome 2.12 running with some amazing eyecandy.
i wish i was but oh well
You, sir, are a magnificent bastard and a glorious ass.
It only sounds resentful if you are looking for resentment. It is a simple matter of fact -- he could not afford it as he and his project are not funded.
Another fact: his lack of funding is contrasted by the fact that others, who are only now investingating issues he has already implemented are well funded.
It is what it is -- factual. So keep your "you got what you asked for" attitude to yourself, thank-you very much.
Yeah, there were a lot of issues there and a lot of unhappiness all around.
One of them was that North Carolina just sucks, which is why we now have an office in Westford, MA.
even better, vidcaps
rasterman's page is slashdotted, but mirrordot to the rescue..
As far as I am aware, if you use X locally, no networking is involved. X uses Unix sockets, which are similar to IP sockets (which is useful because you can easily switch), but not the same. Unix sockets are just one of the ways to facilitate inter-process communication, other ways being shared memory or pipes(?). I am not a Unix geek though, so beware.
Switch back to Slashdot's D1 system.
Well, I run an Athlon64 3200+ with accelerated NVidia drivers but I can't drag or resize an opaque window smoothly. I can't do it under WindowMaker, KDE, GNOME or even E17, and the problems are in the X Server
/compositing model currently used.
I haven't used Windows in years, but when i do see it, the thing that stands out is that desktop rendering is noticeably faster and smoother than any X server I have, excepting maybe my SGI O2 running IRIX.
I also have an iBook running OS X, and while it has problems resizing windows really smoothly (though i can't visibly see repaints like I can under X), everything else feels a lot faster and slicker than XFree86/Xorg etc.
Now, i'm sure it's not the X protocol that is the problem, but the difficulty in synchronising X windows to the VBI and also in the extremely poor implementation of alpha-blending and the rendering
I gots ta ding a ding dang my dang a long ling long
Yes, this is true. However, to add to that, let me say that on Linux, Unix domain sockets are very fast. I believe they are even zero-copy, which means there is no real overhead.
"Anecdotes != Data"
Trying running "x11perf -all" sometime to give you an idea of just how fast an X-server is at executing basic operations.
Obviously, these don't illustrate what the overall end-user experience is going to be like, but they do show how fast the underlying X-server is working.
Neither could I, at first, because the drivers SuSE 9.2 has are inadequate. You have to download and install a better driver from the NVidia Web site and install 'em. You won't get the driver through SuSE updates, either, presumably because the driver comes with the "kernel taint" of its closed-source nature. However, the NVidia video driver install for Linux has always been very good and the latest x64 Linux driver is no exception.
KDE is very pretty these days. Once I got the driver issue solved, it's also as snappy as can be.
Fun with Anagarams! LADS HOST, SHALT DOS. HAS DOLTS. AD SLOTHS, HATS SOLD. ASS HO, LTD.
You sir, are full of crap.
... and that's an EET that was designed to push the limits of what Evas/Edje can do. With GL acceleration that falls to 10-15%.
Let's see here...
The effects usually look professional, but they run slow and inefficiently
Evas is up to 150 times faster than XRender in plain software mode (with no hardware acceleration) at rendering images. In fact, we often prefer running in software mode than in GL mode because it's more stable and often works better. This is the wrongest statement I've ever heard in my life. Have you ever seen Engage? It does the OSX docker effect absolutely smoothly even on a relatively slow CPU and the crappiest of video cards. That complex, multi-layered animated background you see in the video runs on my system smoothly while taking less than 40% CPU
However, enlightenment is way too layered and has a million different little components... I just personally think it could all be implemented better.
So you think it would be better if we had one big monolithic, inflexible library that was full of bugs? Or you're one of those people who think that somehow the EFL is slower because it's componentized -- even though it beats the crap out of anything comparable that exists performance-wise? How does "consolidated" translate into "scalable", anyway, Mr. professor of software engineering?
This technology is there, it has been carefully thought out, solidly and cleanly implemented. Go take a look at the code/API yourself before you begin to comment. It is usable NOW, and you don't need to wait until E17 is released before you can use it. None of those things you see in the videos are simulated, that is presently working software available to anyone who wants to install it.
Am I a hipster-doofus?
I know this is hard to understand for some, but eye candy isn't the primary purpose of a desktop, usability is. A desktop using just black-and-white pixels can be far more usable than one with shadows, transparency, and all those other features.
Also, people should remember that neither Apple nor Rasterman invented features such as the use of translucency, blurring, shadows, etc.--they go back many years in the academic literature as visual clues.
Furthermore, support for translucency itself has been discussed in the X community pretty much since the day X11 was released, and the reason for not adding it has been a high cost/benefit ratio. It's only now that hardware has gotten cheap and good enough that many people can use this, and that toolkits are starting to use it, and that people have the software engineering side under control that people are getting around to adding this feature to X11. From a practical point of view, that's probably about the right time.
The Register
Good enough? There are plenty of benchmarks that reproduce this, if you want to search for them.
It really depends on a number of variables. Do you have ext3 for the FS? Maybe some options are slowing things down. Or maybe debug is turned on for ReiserFS. I mean if someone claims that WinXp is sluggish and we find out that it is on a Fat32 FS that has never been defragged, well...
Just a Tuna in the Sea of Life
IMHO you guys could do a lot for the E project by having an rsyncable nightly build tree for Linux/x86, so it's trivial to try the latest code. That way you'd get more testers as well.
Running Windows XP on a 400Mhz PII with SCSI RAID underneath and it flies. Linux/X11 does not on the same hardware, regardless of optimizations, distros, windowing managers, etc.
There are a number of things you have to ensure:
- you're running a recent kernel, optimized for your hardware
- you're using an accelerated driver (this makes a HUGE difference). If you have recent hardware, this means running a binary driver which isn't likely to be installed by default.
- you have dma enabled (you'd be surprised how many linux machines don't have dma turned on for the drives, which results in only a tenth of normal drive performance)
- you're not loading more software than you have ram for (same rule as windows, run a small enough set of software so it doesn't have to swap in and out parts constantly). This happens less nowadays, but it used to be that a "complete" install would leave a linux system almost unusable because of all the services filling up the ram.
My personal experience is that X is fast and responsive if it and the linux install it runs on are configured correctly. I have an athlon 700 running kde3 which is extremely responsive. OK, so it's anecdotal evidence yet again, but the fact that people do have responsive X systems does say something about X's potential for performance, right?
By the way. Don't switch distro's to try to fix problems. Only switch distro's because you like the underlying philosophy of the other distro better. It's my personal experience that any distro can be made to do anything any other distro can be made to do. It may not be as easy, but it can always be done. After all, underneath they're all running the same code.