Slashdot Mirror
X11 Chrome Reportedly Outperforms Windows and Mac Versions
An anonymous reader writes "In a curious contrast to conventional wisdom, there are reports of X11 Chromium being faster than Windows or Mac versions. In the thread titled 'Why is Linux Chrome so fast?,' a developer speculates that it is due to the use of X11 capabilities: 'On X-windows [sic], the renderer backingstores are managed by the X server, and the transport DIBs are also managed by the X server. So, we avoid a lot of memcpy costs incurred on Windows due to keeping the backingstores in main memory there.' Has the design of X11 withstood the test of time better than people tend to give it credit for?"
X11 has never been a bottleneck in performance on the desktop. Many people have been confusing X11 with the desktop system/kernel/applications and wrongly blamed X11 for any slowness.
HTTP/1.1 400
I like how you took a bunch of graphics and video related words and threw them together in a post that sounds coherent, yet is totally wrong.
After doing a fresh install on both systems the guy determined that it was just some sort of freak occurrence. He had one laptop with a 2.0ghz processor and another with a 2.4ghz processor and after the reinstall on both systems, VOILA...it was only roughly a 20% difference...
TFA - just keep reading further and further down the usenet post
We could also just move process creation to a background thread.
Ok, that's just making the process and subsequent address space.
An unused process might just get swapped out and be no cheaper to "make live" than it would be to create a new process.
It sounds like process just being put into a pool - the process creation thread is holding onto the handle - and when someone wants a new process, the thread just hands over that one presumably the heap and stack for that process would be cleared.
I don't see where there could be a security issues - but, then again, it's been 15 years since I worked on an OS, let alone an Intel based one; I have only 1 cup of coffee in me; I'm still drudging through the posts in the "article".
If you choose your abstraction carefully, you can hide expensive details from user space.
In the short term it may not gain you anything.
But if the abstraction lives and thrives, then much can go on behind the scenes to improve the situation.
Java is another example of this: they carefully designed the language so that it would be possible to make vast simplifiying assumptions and implement optimizations that really improve performance without impacting the "other side" of the wall. Originally java was slow, but hard work behind the scenes means that your java programs run much faster now, without any extra effort on the part of the application developer.
X Windows is a great example of this. Originally we had dumb frame buffers with no acceleration at all. And yet X provides an abstraction that allows lots and lots of hardware optimizations to take place.
The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.
How about a Qt build of Chromium as opposed to a GTK build of Chromium? I'd be real curious to see how it performs.
I was also saddened to see the port team bitch and complain initially that they had to use GTK, because GTK is "the standard toolkit" for Linux, while in the same paragraph complaining that Linux doesn't simply have one standard toolkit. Last time I checked, Windows has a bevy of toolkits and APIs to choose from as well. They also complained that writing audio in Linux was difficult.
If they had written a Qt app from day one, porting would be minimal, they wouldn't have to maintain this huge separate trunks, it would have worked from day 1 on Solaris, Mac, Linux, Windows, BSD, etc. Audio would have been very easy to code with Phonon.
I'm curious to see if Chrome (the browser and OS) are indeed both developed with GTK, then will they both need some retrofits when GTK 3.0 ships, further complicating the matter?
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
It's been called X-Windows for a long time. Longer than the term "X11" has been around. It's not a misuse of Microsoft's Windows® brand name.
I read TFA and all there is are feelings of some people that its faster, no numbers. I guess that is what "reportedly" means. Weasel words.
That logic makes significantly less sense than the fact that it's ultimately based on Konqueror, which was designed for X11 (and Linux) to begin with.
X has it's problems. It also has it's advantages. Some of those
advantages aren't so much a matter of X itself but side effects
of the old school Unix way of approaching a problem.
Seeing MacOS going through vnc side by side with X apps being
run remotely (and viewed locally) certainly gives me no
burning desire to get rid of X.
A Pirate and a Puritan look the same on a balance sheet.
MS Windows = Explorer.exe
Linux = X11
MacOS = Quartz
That this is marked up as informative really shows how bad slashdot has become. You losers are even shitty at being computer nerds.
The UNIX Hater's Handbook, which is a little bit out of date now, goes into the design errors of X. It's worth reading if you're wondering why X drives people nuts.
The handbook may be out of date, but that section on X is just as true today as it was then. This part in particular hits the nail on the head:
(The idea of a window manager was added as an afterthought, and it shows.)
If X outperforms anything, it is by sheer luck and unexpected consequence. The planets align "just so" and for once it is the best implimentation for a particular task. It is not a common occurance. Coming to the conclusion that it "stood the test of time" based on a single piece of software is rather foolish. If X regularly out-performed Windows and Mac this would not be a surprise, but of course, it is a surprise.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
, and it has a client server model because originally the display was normally on a different machine than the server (this is often raised as a bad design)
You should read that section on X the GP posted, they actually tried to use X for its intended purpose (back when that actually was an intended purpose, and had not been hacked around yet) and found it nearly useless as a remote display server/client setup compared to other setups, most notably Sun's at the time. It was arbitrarily devided into client/server (and "client" and "server" roles were reversed from convention, for some strange reason) without much rhyme or reason, which made it a bandwidth hog and meant half the graphics application had to reside on the client (the end computer the graphics, not X's retarded definition of client) anyway.
Except that it wasn't. For the longest time X11 was the most bloated and slowest option out there, for remote and local applications alike. The only reason it is fast now is because hardware has moved so far beyond it that it is fast in spite of itself. It certainly isn't nearly as powerful as any other GUI system, and when you actually add on all the bells and whistles (which must be created separately by somebody else) it's still slower than anything around. Seriously, add the necessary components to make X11 match Windows XP/Vista/7 or Mac OSX, particularly a good window manager window dressing from Compiz, and you'll find almost everything GUI-based runs slower on X11.
That Chrome is an exception is shocking, and is why everybody is surprised, hence TFA.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
The only terminology I have ever heard of calls the X server "server" and applications using it "clients". Perhaps you are referring to the fact that the X server typically executes on the client computer (the user's computer), because that's where the keyboard and screen is, while the application (client) sometimes executes on a server computer, to which the user might have connected using a remote shell (such as SSH).
How much of the graphical user interface evolution on UNIX has been put back because the varying WMs and toolkits?
It's better now that we're down to X.org and GTK or Qt, but years were wasted because you couldn't write an app that took advantage of, say, Display Postscript or multi-head or decent colour-correction or a given GUI toolkit without restricting your market.
For a very long time---and ending not so long ago---state of the art, cross-platform GUI toolkits on UNIX started and ended with Motif. That's horrible.
That doesn't really speak to the question of whether the window manager should be built-in...
I mean, I don't want to sound like the situation is all roses here. Yes, as you say, there's been a lack of focus that has detracted from the overall experience. But, you gotta look at the bright side, too. Suppose Motif and/or mwm had been integrated tightly into the X server... Where would we be now? We'd still be stuck with it, probably... Would we really be happier knowing that a clear direction had been chosen, if that clear direction sucked?
I think the lack of focus is an unavoidable consequence of a system that's developed without clear-cut, authoritative leadership. That's a down-side of using a system that's not been designed by a single group like Microsoft or Apple. But the up-shot is that a system like that is open to experimental ideas. The result isn't a true meritocracy of software (that is, no matter how good a piece of software you might write for a particular task, there are still practical problems in terms of getting people to invest themselves in using it) but there are always options...
Going back to the question of tighter integration of the wm with the X server - I remain unconvinced. I could see how X could benefit from better compositing support and other features to make wm's behave better, but I don't see what the benefit would be of having the wm built right in to the X server. It seems like running it on the local machine is just as good...
Bow-ties are cool.
I always thought of it this way: XServer provides display and I/O services to the client applications. Client and server may be on the same machine or not.
*drag*
*drag drag drag*
*drag all over the screen as fast as I can like an angry monkey on crack*
Nope, don't see any tearing. CLOSED WORKSFORME
The window manager should have been part of X from the get-go.
The window manager should NOT be part of X. Choice of window managers is a good thing. And what is even better is choosing and changing window managers without logging out. Or running them in different windows (really handy sometimes.)
99% of users don't do that you say? I don't care. It's nerdy goodness, and this is news for nerds.
By that user-centric logic, however technically incorrect it may be, X's names ARE reversed.
Only in computers would you see people advocate for precise technical to be defined to be defined by non-experts.
Nobody argues about what a "normal distribution" is, or what "adaptive chosen ciphertext attack" is, but if you talk about "client/server", now everyone has an opinion.
http://outcampaign.org/
I think it's only the persons that call the terminology reversed are the ones that are backwards. It's very logical to me.