Linked by Guillaume Maillard on Thu 10th Oct 2002 05:44 UTC
Being a BeOS user (a purely desktop system) and because I code under Linux, I see XFree86 (v4.1 on my machine) as a user and as a developper. And this is where the problem lies. My Gnome or KDE desktops are slow in comparison with other operating systems, but XFree86, the 'engine' behind these desktops, proves me that it's not. Let's look at what I have in front of me: a dual Pentium III at 933Mhz with 512MB of memory, a Radeon 32 AIW, a modified Mandrake 8.0 powered by kernel 2.4.18.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
This was a pretty good article. I'd just like to add some things on top:
1) Qt and GTK+ don't use XFree as efficiently as it could be used. They do a lot of rendering, in software, in client space and send a lot of bitmaps to the server. I don't know what kind of problems drawing lines and whatnot the author was having, but on my system, I get about 194,000 lines per second, a whole lot more than what the author got. In reality, (with good drivers), letting the server do the rendering is a much better idea than shipping a large amount of data through a socket.
2) Quartz's bites. It has so much potential, using a 100% vector graphics API, but it keeps hundreds of megs of giant bitmaps around. In my Linux install (KDE 3.1-beta2) I can move (and resize and whatever) Windows all I want and there is no flickering or redraw lag in properly written (KWord, etc) applications. And I can actually use all the RAM in my laptop instead of having 640MB just so Quartz runs acceptably.
3) You can't "install" SHM. It's already built into every X server. Qt 3.x uses it for some operations (big pixmaps) by default.
4) fbDRI is a great idea. Something like that combined with EVAS and E17 is exactly what Quartz should have been.