OSNews reader Andreas writes: “Recent additions to 2.5 dev kernel (2.5.65 will contain the changes) that heavily improves desktop interactivity smoothness. It’s easy to overhype so I won’t but I’m running patched 2.5.64 and the difference are without a doubt more then just “noticable”. Here’s the story at KernelTrap.“
Beta Linux Kernel Now Offers Extra UI/Desktop Responsiveness
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Where can we get it?
Or more specifically… When can I expect the sources to be released so I can tweak up my Phoebe install?
Dammit! Normal people (non-kernel hackers) want desktop responsivness too!
8)=
Seriously… Anyone have the patched kernel? Is it all hype?
Dammit! Normal people (non-kernel hackers) want desktop responsivness too!
You bet.
About XFree’s ‘startvation’ for ressources and a new scheduling for this (several) processes … wouldn’t it be better to start thinking about a replacement for X ?
IMHO desktop responsiveness would improve without arming the applcations performances.
(Linus’s regular PC has 4 fast cpu’s ? – Are those Transmeta crusoes ? – He must be able to compile a new kernel very fast with it)
Replacing X is not the solution.
Why? Because X is not the problem. Any process that did the same thing would be in the same situation. What you see in the thread is just an example, which is easy to trigger with common software.
I don´t, so let me start by saying that even if Linus had 4 Transmeta cpu´s on the mainboard of his regular PC (which, BTW, I am almost sure he doesn´t), he wouldn´t compile the kernel much faster than your average Athlon XP 1600+.
Apart from that, it is highly unlikely that a ¨new kernel¨ (actually just a patched 2.5.64 kernel) would improve desktop responsiveness. It´s like changing the sparkplug in your car and exclaiming ¨Wow, it´s got more power now, I can **feel** it¨… Yeah, sure.
So, don´t rush off to download and compile your shiny-new-and-patched 2.5.64 kernel. There is a lot more to ¨desktop responsiveness¨ than just a tweaked kernel.
But I have a question. Will this be one of those speed-hikes which makes a noticeable difference to speed only if you have a recent system and will in fact be slower on lder hardware than the code it replaces? ( IE KDE 3 )
OLDER not lder
EG not IE
So, don´t rush off to download and compile your shiny-new-and-patched 2.5.64 kernel. There is a lot more to ¨desktop responsiveness¨ than just a tweaked kernel.
Why not? That’s the great thing with Linux, you can go out and do this for free and fun if you have about 30 minutes of time to spare and a will to explore. Kick the methaphorical tires a bit, measure it, try to break it, even if it only feels faster it’s all good. And changes in the scheduler can have serious effects on interactivity, it’s hardly a “spark plug patch”.
http://slashdot.org/article.pl?sid=03/03/08/162218&mode=thread&tid=…
some good info in this thread on the how and why and stuff.
-Nex6
No, especially not your comment. You’ve written a 3 paragraph response as to why this won’t speed things up and all of it is based on conjecture. You offer no actual proof to assert your argument. For anyone that has back-ported the low latency, scheduler and pre-emptive multitasking patches from the 2.5 development series to the 2.4 stable series of kernels, they realize that relatively simple patches can make a huge difference. If anyone wants to have a nice boost in performance they will notice, I suggest they try the Con Kolivas set of bundled 2.4.20 desktop patches. Much of these patches are what will be found in 2.6 when it is released.
> Correx to above
> By ~CdBee~ (IP: —.cache.pol.co.uk) – Posted on 2003-03-> 08 19:04:21
> OLDER not lder
> EG not IE
Oh, and it’s corrects. Actually, e.g. & i.e. are both correct terms.
Michael Lauzon
Founder & Lead Project Manager
InceptionOS Project
http://www.inceptionos.org/
[email protected]
http://newark.rutgers.edu/~jlynch/Writing/e.html#eg
This has been an option in practically every version of windows since Windows for Workgroups. And you can change it without recompiling your kernel.
Imagine changing Linux so it is more responsive to the user. Like, wow, what will thesse guys think of next.
Wow, a little bit of knowledge really makes you look ignorant. This is about prioritizing processes that interactive processes rely on. Not prioritizing the interactive processes themselves. Windows doesn’t do this.
Well, BeOS has been doing this for years, it would be nice Linux began to get closer to this
linux’s future is so bright, we gotta wear shades. 8)
<< It´s like changing the sparkplug in your car and exclaiming ¨Wow, it´s got more power now, I can **feel** it¨… Yeah, sure.>>
You might want to use a different example, because you CAN gain more power and feel the difference by changing spark plugs
“Apart from that, it is highly unlikely that a ¨new kernel¨ (actually just a patched 2.5.64 kernel) would improve desktop responsiveness. It´s like changing the sparkplug in your car and exclaiming ¨Wow, it´s got more power now, I can **feel** it¨… Yeah, sure. ”
A better analogy would be like changing the engine in your car to a more powerful one. And yes, then you can “feel” it.
You seem to be completely misinformed as to what the kernel actually IS.
No, I don’t, and neither do the kernel developers.
That’s why they use benchmarks to test and refine interactivity under load, latency times etc.
There is no point in making changes to the schedular unless you benchmark afterwards. Load is simulated and response times are measured.
The Windows solution to this is kind of a hack. Windows simply gives more CPU time to whichever process’s window has focus. Also, it gives temporary priority boosts to processes that use certain devices (like the sound card). It works most of the time, but when the machine gets heavily loaded, interactivity oftens falls through the floor. Beyond that, it’s isn’t really “clean” to put so much knowledge about the GUI into the kernel. What the Linux people are trying to do (I’m still reading the mailing list thread trying to understand exactly what they’re doing
is to find a more general solution.
Maybe we should all buy 4 Intel XEON MP’s, and enable HT.
>The Windows solution to this is kind of a hack….It works >most of the time, but when the machine gets heavily >loaded, interactivity oftens falls through the floor. >Beyond that, it’s isn’t really “clean” to put so much >knowledge about the GUI into the kernel. What the Linux >people are trying to do (I’m still reading the mailing >list thread trying to understand exactly what they’re >
>doing
is to find a more general solution.
But Linux interactivity is through the floor most of the time. This is better? Also, I guess when the new kernel still has responsiveness problems, we can rest assured that it’s better engineered than solutions (Win, Beos) that actually work? Gimme a break.
You’ve got to pound a Windows 2K or XP machine pretty hard to lose responsiveness. My linux box takes 5 seconds to show a File–>Open menu. But at least it’s open source.
<<You might want to use a different example, because you CAN gain more power and feel the difference by changing spark plugs
>>
I think he was just humorously trying to point out that he knows as much about kernels as he does about cars.
Replacing X is not the solution.
Why? Because X is not the problem. Any process that did the same thing would be in the same situation. What you see in the thread is just an example, which is easy to trigger with common software.
You’re wrong, X is the problem. And there are solutions, namely directfb. The problem is that directfb lacks drivers. A good compromise solution would be an hybrid environment in wich you would have both native directfb apps and if for some reason someone needed the network transparency of xfree86, an xfree86 server built on top of directfb (it’s a thin lib) would run X11 apps.
Anyway take a look at some directfb screenshots running gnome (shameless plug:)
http://www.directfb.org/screenshots/index.xml
Linux isn’t amazingly cool because a bunch of nobody’s came together 12 years ago and created a digital miracle. It’s a relatively new piece of software, under constant development. One of the things that comes out of this situaltion is that Linux is great at a lot of things by now, but still has yet to implement technologies / methods that are getting to be expected in older, more mature systems. But since they’re already around in other pieces of software, it doesn’t take a *whole* lot for kernel developers to design a new thing and implement it. There have been several times in kernel history where all of a sudden, certain kinds of workloads got a huge shot of steroids. This is probably one of those things.
So far, Linux kicks ass as a server. Several past patches have made sure of that. Lately, we’ve been taking a more deliberate approach at the desktop, having mostly conquered servers while lagging in desktop areas. Because of this shift in focus, patches like this come out, and once it’s more thoroughly tested and maybe better implemented, it’ll be nothing more than another patch in kernel history that added another big building block to the project (which we all appreciate implicitly!).
Don’t change spark plugs,
buy a new car and shredder the old.
An old car pisses you off,
even if you skrew on it day by day.
By the way reading Linus E-mail makes me wonder
if he really knows what he is doing.
The windows approach is “give more priority at the focused window” (i ignore what BEOS does). Yeah, linux _can_ do that, but it’s _ugly_. It means “our OS sucks so we need to boost the focused window so user feels it’s very interactive”. What a crap.
Until now, linux used almost the same approach -renicing the X server to ie: -10 – which is ugly too. The patch is already mergeg in 2.5 (wait a pair of days to 2.5.65). The patch means “our OS knows to detect interactive tasks and he knows how to handle it”
So, X applications can run on DirectFB? Also looks like the font rendering in DirectFB is great!
> Actually, they are not interchangeable…
> By Joe (IP: 65.96.7.—) – Posted on 2003-03-08 19:28:38
> http://newa rk.rutgers.edu/~jlynch/Writing/e.html#eg
I never said that they were, I just said that both are correct, as in they are both used in the English language.
Michael Lauzon
Founder & Lead Project Manager
InceptionOS Project
http://www.inceptionos.org/
[email protected]
So, X applications can run on DirectFB? Also looks like the font rendering in DirectFB is great!
Yep: http://www.directfb.org/news/dok/xdirectfb-1.0-rc4.xml
It´s like changing the sparkplug in your car and exclaiming ¨Wow, it´s got more power now, I can **feel** it¨… Yeah, sure.
This has got to be one of the worst analogies I have ever seen. The kernel decides what resources go where. It is the brain of the OS. In a car, I guess it would be the engine. If the kernel is starving x for resources then a kernel improvement really could boost desktop performance. I am not saying it does, but I am saying it is more than possible.
The windows approach is “give more priority at the focused window” (i ignore what BEOS does). Yeah, linux _can_ do that, but it’s _ugly_. It means “our OS sucks so we need to boost the focused window so user feels it’s very interactive”. What a crap.
What the hell are you talking about, the windows gdi works totally diferent than x11, the gdi runs in kernel level, it’s not a process in userland like x11, so how do you change the “priority of the focused window”? it doesn’t even have a window manager O_o
Besides how could you know how the gdi work do you have the source code of it? 😀
I noticed that a Rover was much faster with a new sparks BTW….
What the hell are you talking about, the windows gdi works totally diferent than x11, the gdi runs in kernel level, it’s not a process in userland like x11, so how do you change the “priority of the focused window”? it doesn’t even have a window manager O_o
Besides how could you know how the gdi work do you have the source code of it? 😀
Really? if Windows dos not have a window manager then how come IE replaced Windows Explorer, and can be replaced by LiteStep and so forth.
It probably chanegs the kernel priority.
Linus says lets do thinsg right and not use hacks. This personally sounds great to me. This should help on older and newer systems too. This also fixes problems with programs taht are not as noticable. You X11 naysayers, what are your arguments still when you comment on how slow it is when thinsg like 2.6 can change the responsiveness? How much of it is X and how much of it is everything else. I personally would love to see Fresco advance but am perfectly happy with X for now.
Im nto sure but Im guessing this does not change CPU intensive stuff as much. This is more of a matter of When you process and not if. Interactive stuff needs to respond with less latency while just CPU hogs can happy in any nook and crann as long as it gets done.
Geez there are a lot of people here making CompUSA salespeople look like computer engineers.
Yes GDI is in kernel and has been since NT 4.0. Windows NT and its derivatives by default give preference to “foreground applications”. That is, the application that is associated with the window currently in the foreground and being used by the user. You can change this, and probably want to if you’re running a server, by giving preference to background applications.
GDI is to Windows as X11 is to Linux. They aren’t even close in implementation but for all intents and purposes they accomplish the same thing. Explorer.exe is to Windows as KDE/GNOME/WMs are to Linux. Again, the implementation is a great deal different, but the end result is similar at least from a user perspective. One can very easily change Explorer.exe with something else, such as Litestep as somebody has mentioned.
I’m a Linux user, but I one of my biggest pet peeves is the crappy desktop responsiveness. To me, having the GDI in kernel is a worthy trade-off. Believe it or not, Joe Blows particularly notice how “snappy” a program feels. I would love for Linux to accomplish the same effect. It isn’t doing it now, and I’m not a particularly ideological person – I don’t care how they go about accomplishing it. To me, this is a big step in the right direction though.
Explorer is a file manager. If you kill it in task manager, your apps will still run (with their title bars etc.). I wouldn’t confuse it with the X11 concept of a Window Manager – Windows manages its windows in the kernel, and doesn’t have a seperate “window manager”. Using system wide Hooks you can override the sizing and painting of all window frames, by running your own code instead, but you are simply bypassing the kernel functionality (this is what litestep and others do – in fact I wrote a window painter for NT4 way back in 1996 because I wanted gradient title bars which NT4 didn’t have).
In Windows, the focused *application* recieves a higher priority, not the GDI code inside the kernel. This allows the *application* to process its application messages such as mouse clicks, repaint requests etc. faster. It is not all that bad an approach really when you think about it. It is actually giving the *user* priority, guessing that if an application has the focus, it is probably being *used* by the user. I for one want my computer to put *me* first. If I want to click on something, then I expect it to happen and not be pre-empted by some file searching tool.
For what it is worth I have ran X11 with near perfect responsiveness without the new Linux kernel but I cannot say how right now ;o) Hehe.
Jamie.
Geez people look this stuff up. Explorer.exe is actually the Windows shell too. Here’s one of the first links I found off of google by searching “explorer.exe windows shell”, since nobody seems to believe anybody that asserts it to be a shell.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/…
> Explorer is not just a file manager
> By Anonymous (IP: —.cpe.net.cable.rogers.com) – Posted > on 2003-03-08 23:11:31
> Geez people look this stuff up. Explorer.exe is actually > the Windows shell too. Here’s one of the first links I
> found off of google by searching “explorer.exe windows
> shell”, since nobody seems to believe anybody that
> asserts it to be a shell.
> http://www.microsoft.com/technet/tr eeview/default.asp?
> url=/technet/…
Yes, Explorer.exe is a shell and file manager, while iexplore.exe should not be confused with the aforemention application…although there are people who do mistake the two.
Michael Lauzon
Founder & Lead Project Manager
InceptionOS Project
http://www.inceptionos.org/
[email protected]
X really isn’t unresponsive. If you “nice” it properly, it’s actually pretty damn responsive. I run Gentoo, so I’m always running big compiles in the background. Often, I don’t even realize a compile has finished, because I wasn’t noticing any slowdown anyway. Yes, I have it “nice
‘ed” which *is* a hack. But that hack isn’t really any different from the hacks Windows uses, so it’s a fine interim solution while the Linux guys come out with something more general. And I’d point out that even BeOS uses this hack: window threads ran by default at a higher priority (60, I think).
As for putting X in the kernel, it wouldn’t help much. Running a program in the kernel doesn’t automatically make the program run faster. The only thing it does is make it cheaper for an application to call into it. The overhead of running X in a seperate process is the same as the overhead of UNIX domain sockets vs kernel calls. On Linux, UNIX domain sockets are very fast, so the extra overhead isn’t all that much. Further, Xlib was designed to minimize the number of system calls made, so the overhead is largely irrelevent. Again, I’d point out that BeOS used an external window server, just like X.
If you take a look at applications which only stress X itself (apps that consist mostly of widgets, like QT Designer, KFind, etc) you’ll see that X redraws just as fast as the Windows. What responsiveness issues you do see, like rubber banding in Konqueror or the tendency of gradient-toolbars in KDE to lag behind the window while resizing, have more to do with unoptimized redraw behavior rather than pure speed bottlenecks.
I’d like to see some DirectFB vs X benchmarks. DirectFB looks interesting, but I really don’t think it’ll be all that much faster than X (given well optimized drivers like NVIDIA’s) and it has some major issues (lack of hardware OpenGL) that could be deal-breakers.
window managers != win32 shell
read this:
http://home.pacbell.net/kache2k/shell-if-i-know.html
Litestep still uses the gdi to manage windows.
Probably the only to use a window manager in windows is to run the xfree86 server ( http://www.cygwin.com/xfree/ ) and use some other desktop environment ( http://kde-cygwin.sourceforge.net/ )
I love the stories on this site, but the message boards are full of people really talking out of their asses. How many people here that make comments about technical issues involving code really develop software?
Well this is just a comments section.. so take everything here with a grain of salt. I mean you don’t go throught he /. comments analyzing everything everyone posts do you?
If you don’t like any of the idiotic comments (which I find hilarious) then don’t read them. Personally, I find the comments sections of this site great, gives me and my co-workers things to laugh at.
I’m just wondering Chris: why are you reading the boards then?
If you don’t like them, I’m sure your iexplore.exe has a back
button and your GDI has a close button. Oh well, explorer.exe
might even have a File->Exit menu item.
The BeOS GUI feels good partly because of the fine-grained kernel, but more importantly, I’d think, the high usage of threads provides an illusion of responsiveness. Every BWindow (C++ object) spawns a thread of its own(*), with a higher priority. For time-consuming operations, like number crunching or disk access, you would (or should) use normal-priority worker threads, separate from the GUI. It’s more illusion than “oomph”, but it keeps me happy all day. BeOS is far from perfect, as is Linux, but at least it’s got the right feel.
(* actually two threads.. one in the app itself and one in the app_server, BeOS’ GUI server)
OpenBeOS.org could use some more devs, BTW, especially good kernel devs, device driver writers and people skilled in writing quality C++ code.
And why do you think directfb will solve this problem?
Go read the whole thread in kerneltrap. Basically any server process that hogs CPU in bursts and waits on processes that sleep() is going to show this behaviour.
Doesn’t directfb use a server? If it does, it’s the same thing.
If it doesn’t use a server, well, it’s a whole new argument.
DirectFB looks interesting, but I really don’t think it’ll be all that much faster than X (given well optimized drivers like NVIDIA’s) and it has some major issues (lack of hardware OpenGL) that could be deal-breakers.
I too am quite interested in DirectFB. Obviously there are things X has right now that FB doesn’t, but DirectFB is young so possibley these things are forthcoming. Obviously hardware OpenGL is the most important one right now and should probably be a primary focus.
Wee, both quite off-topic, and feeding a troll, but i couldnt resist 🙂
It´s like changing the sparkplug in your car and exclaiming ¨Wow, it´s got more power now, I can **feel** it¨
If you actually want a car analogy that would fit, then you could compare these kernel patches to having your car chip tuned.
Where this one works is that the chip tuning is indeed tweaking the “kernel” of the car, and it can often[1] increase the cars performance. The difference is of course that the developers are trying to optimize the default software so you dont have to tune it manually, which you often need to do today with the linux kernel. (i personally have both X and my sound server and XMMS running at -10 priority)
[1]: Often, but not always. Not two engines have the exact same characteristics. What the mechanic is trying to do is to optimize the software for your exact engine. I have heard of results adding 10-15% extra HP, while keeping the fuel economy untouched.
</offtopic> 🙂
You’re wrong, X is the problem. And there are solutions, namely directfb.
I don’t know if DirectFB is necessarily a solution. It’s fine for a backend, but you really need a process which coordinates things like the clipboard, focus control/priority, window resizing/replacement, etc.
The problem is that directfb lacks drivers. A good compromise solution would be an hybrid environment in wich you would have both native directfb apps and if for some reason someone needed the network transparency of xfree86, an xfree86 server built on top of directfb (it’s a thin lib) would run X11 apps.
This works, and is a better approach than anything I can suggest seeing as how the code is already there.
My suggestion would be a new window server, one where applications draw to a shared memory space directly, as opposed to the shm extension to X, which is used to transfer pixmaps. The main problems arise in things like handling exposes. Exposes remain a terrible problem in X, as clients must still repaint exposed sections of windows, instead of leaving that responsibility where it belongs, the server. The amount of work left to clients in the X model is ridiculous, especially considering the high level of abstraction that GUI programming is typically done at.
Using shared memory raster buffers is advantageous for the following reasons:
* Low level access is still possible for applications which require it, without requiring a separate interface.
* Server complexity is kept to a minimum. Things such as window decoration/font handling are done on the client side, meaning that the server need not become an increasingly large ball of kruft to maintain backwards compatibility.
* Exposes are handled server side, meaning that an unresponsive application will never lead to display corruption
This model is employed by OS X. Windows will also use a raster buffer for applications which utilize transparency.
Windows, of course, had an advantage in that the window server is not a userspace process.
Wow, you mentioned everything Fresco has got or striving for… 😀
This is closer to changing the fuel injector timings then it is changing the spark plugs. I for one am glad to see its an area that Linus et al are still working more on.
Ya know, a lot of people say X is slow, or X is a problem, or X is the cause of some disease in both Bulgaria *and* Canada, or that it’s bad cuz it can’t make my bed for me, but it’s been my experience that X is rarely a cause of problems. I think a lot of people scapegoat X for being slow when it *appears* to be slow, but is actually just another rising star in the open source world, full of wonder and peril alike, but always improving (at least XFree is, I think, not sure about others). Not to say alternative projects are unneccesary or not good, cuz at the least, they’re good.
ok… Assume the kernel is not verstile enough to GUESS what the **** the user is doing. ( fork(random_process_x) ). how about the kernel actually seeing that x is starving and being able to balence the load Xs way, or after the screen saver kicks in, balence the load to the webserver.. ( Hey look at that.. my screen saver goes slower then I transfer files )… mabye we might even be able to catch up with BeOS, or god forbid pass the AKC window wiggle test better than a 12 year old Amiga. You cannot only observe the past, but perhaps even learn from it.
“MOTTI: Don’t try to frighten us with your sorcerer’s ways, Lord Vader. Your sad devotion to that ancient religion has not helped you conjure up the stolen data tapes, or given you clairvoyance enough to find the Rebel’s hidden fort…
Suddenly Motti chokes and starts to turn blue under Vader’s spell.
VADER: I find your lack of faith disturbing.”
process_fork( return_0 ).
finding out what Eugenia thinks about these changes, she’s usually very picky about things like UI responsiveness and seems to notice what alot don’t (atleast points it out). Try out this new kernel and give us a tiny story or a decent sized comment one of these days.
Those that propose to seek a replacement for X must be complete *NIX noobs.
The single most entrenched piece of software must be X, you can never get rid of it.
And no one would want this either, X might be slow for you, but providing a GUI with total network transparency (like X) would always be slower than your f*gg*t WinXP box.
Hopefully this work will contribute much to the improvement of GUI responsiveness. By the way I’m not quite confortable when someone say X is slow and need to ber replaced because;
i. I’ve heard this kind of comment since the last few years but there are no single project that have succeeded so far (such as PicoGUI, Microwindows, DinX (dead?), Directfb, Freesco/Berlin etc). But at least the guys that works on this project does tried and did a good works which I think was not done by the person that alway say “REPLACE X!!”. And, please be noticed that this project was few years old and still not as usable as X. However I must say keep on your works guy so that at the end we can have choices of GUI system.
ii. If anyone ever tried different kind of Window Manager, he/she should have noticed that different WM give different responsiveness. For me the most responsive WM (or DE) is EDE where its own application just pop up immediately after I click the mouse, but other application that not using FLTK remain crawling although faster compared to when it run under other WM or DE. I’m hoping that by time, all other toolkit/application will fix their problem and lead to faster application.
And of couse we should note that innovation normally for the better as what the kernel man are doing.
Those that propose to seek a replacement for X must be complete *NIX noobs.
Thank you for the personal insult. However, I don’t think my place of employment, my years of experience, or my position as a Unix hardliner really qualifies me as a “*NIX noob”
The single most entrenched piece of software must be X, you can never get rid of it.
Well, first, you’re missing several key issues:
The use of a shared memory-based display server eliminates X11, not xlib. It permanently solves all compositing issues in X, especially those relating to client side handling of exposes.
And no one would want this either, X might be slow for you, but providing a GUI with total network transparency (like X) would always be slower than your f*gg*t WinXP box.
Making network transparency an inherent part of the display server architecture is a foolish endavour. High level solutions exist from several vendors for the same problem domain, and all are far more elegant.
The foremost example would be Sun’s Sunray architecture. The session management integrated into the protocol surpasses any other technology. The display protocol itself is probably the best remote display protocol in existance. And this is coming from Sun, the company that chose to forego NeWS in favor of standardizing upon X.
My suggestion would be a new window server, one where applications draw to a shared memory space directly, as opposed to the shm extension to X, which is used to transfer pixmaps.
Which means you lose ‘free’ network transparency.
And you lose the pixmap cache, so your memory requirements go up – every app does its own pixmap handling.
It becomes much more difficult to implement graphics acceleration. All you can really implement is blitting from your offscreen surface(s) to video RAM. You have to have offscreen surface(s) for your apps to draw to because otherwise it would be dreadfully ugly watching them repaint without acceleration. So your memory requirements go up some more.
The tradeoff is that it’s much simpler to write, and compositing becomes dead easy.
I don’t get it. The main problem people have with X is that it’s ‘slow’ and ‘bloated’ (I think it’s quite acceptable myself, but still it could be faster and leaner), not the crufty API (which is well hidden by toolkits). Yet you advocate a design that, in its most widely-used implementation, MacOS X, is demonstrably slower and more bloated than X. What gives? I know Quartz Extreme has improved the speed problem somewhat, but only if you have a beefy 3D accelerator, and it’s done nothing at all for the insane memory usage.
Exposes remain a terrible problem in X, as clients must still repaint exposed sections of windows
Which can be fixed by using SaveUnders and BackingStore. Or rather could be if the implementation wasn’t broken in XFree86. Still, that’s not really a good reason to throw away XFree86, more a reason to fix it. It works on other X servers.
The expose model is something which is slated to be fixed in XFree 5. Keith Packard has already done some preliminary work on this – I think there’s a paper on his website.
The state of Xlib isn’t an issue for most people because of the existence of high level toolkits like GTK and QT (the same applies to windows of course – Win32 is pretty crufty, but most programmers are using higher level wrappers).
What the hell is Beta Linux? It sounds a distribution name. Call it Linux 2.5.x
😛
So here we go again. Somebody on the lkml exclaims that he can ¨feel¨ an improvement in ¨desktop responsiveness¨ and thousands of kernel source tarballs get downloaded and compiled…
As Al Pacino would say: Hooo Waaah
Just like the spark plugs, this also reminds me of those washing machine soap advertisements, when the (pretty, but not too much) housewife confesses to the interviewer that, thanks to the new formula, she can now ¨feel¨ how softer her laundry is, the colors brighter, etc…
Actually somebody managed to provide one good bit of information (actually it was more like a hint of a bit, or .30 bits by my… feeling), that was the name of Con Kolivas, which led to a little search on Google, which led to his page on kernel patches
http://members.optusnet.com.au/ckolivas/kernel/
which led to his interesting ¨system responsiveness¨ test, aptly called contest. (http://contest.kolivas.org)
I doubt anybody cared to run his benchmark on 2.5.64 with and without the mentioned patches, but does it matter?
Interesting, but is this really relevant to ¨desktop responsiveness¨? Nope.
Go ahead, upgrade your kernel every week, and marvel at the improved ¨desktop responsiveness¨. Change your spark plugs too, and ahh, don´t forget to upgrade your washing machine soap.
Hoo Waaaah
Hmm….could we get sun to open up the NeWs server since it’s been abandoned? I know it was definitely ahead of its time. Extra bonus was that it was compatable with the X protocol.
Firstly, window resize lag is caused mostly by a bad scheduling algorithm inside the X server, not really slow redraw on the part of the toolkit.
Secondly, as has already been pointed out, XFree isn’t really all that slow, but its current implementation of XRender is – enabling AA text for instance gives a big performance hit.
Finally, as marm has pointed out, accelerated backing store and save unders is the way to fix this, and is also required for drop shadows/translucency etc, but more work has to be done on XRender and XAA first.
its current implementation of XRender is – enabling AA text for instance gives a big performance hit.
This is true, depending on which graphics card you have. NVidia’s binary drivers accelerate XRENDER and I think the Matrox ones do as well, to a certain extent. Obviously if there isn’t any hardware support, you have to fall back to software rendering which is inevitably going to be much slower.