X11 Chrome Reportedly Outperforms Windows and Mac Versions 542
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 problem. (Score:5, Insightful)
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.
Re:Even if X is usually slower... (Score:5, Insightful)
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.
20% faster on his 20% faster machine.... (Score:5, Insightful)
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
Re:I read the article. So sue me. (Score:2, Insightful)
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".
Choosing the correct abstraction layer (Score:5, Insightful)
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.
Other performance gains (Score:5, Insightful)
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?
What's with writing "[sic]" after "X-windows"? (Score:3, Insightful)
Guestimates (Score:2, Insightful)
Re:X11 has never been a problem. (Score:1, Insightful)
people should be blaming B-Bus, GNOME and GTK+ for performance issues of Linux desktops, not X11.
Re:It's Chrome OS (Score:1, Insightful)
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.
Re:Even if X is usually slower... (Score:3, Insightful)
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.
Re:Choosing the correct abstraction layer (Score:3, Insightful)
Isn't DRI not so much a part of X11 as it was the original Linux "community" attempt to address the functionality that nvidia came by later and fixed?
Re:Windows and OS X versions, please. (Score:3, Insightful)
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.
Re:X11 has never been a problem. (Score:3, Insightful)
Yes, exactly. X11 ran reasonably complicated applications 20 years ago on hardware that we throw out as woefully inadequate (or quaintly archaic) today
But that was in an environment where the average PC had a 640x480 display with 16 or maybe 256 colours. High end workstations had higher resolution but were often monochrome. The X server simply didn't have to do anywhere near as much work as a modern one.
Re:So in other words (Score:5, Insightful)
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.
Re:Choosing the correct abstraction layer (Score:4, Insightful)
"X11 doesn't expose that kind of stuff."
I'm not talking about the stuff that is exposed. I'm talking about the things that are NOT exposed. X11 runs great over the network because of all the things that they chose to NOT allow the user to do.
Sure you can accelerate bit-blitting, that is really old school.
Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond. Try moving the window of an unresponsive app, it does not redraw because Windows is asking the app to redraw it. When you move the window of an unresponsive app in X, the window redraws because X already knows what it needs to know about redrawing the window without having to make a trip back to the application.
Those are the kinds of things that you DON'T expose. That way the driver and hardware are free to implement them as they see fit.
Re:So in other words (Score:5, Insightful)
, 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.
Re:Windows and OS X versions, please. (Score:3, Insightful)
For and against tighter integration of wm's (Score:3, Insightful)
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...
Re:So in other words (Score:3, Insightful)
Re:X11 has never been a problem. (Score:2, Insightful)
What are you talking about? I was using X-forwarding from the University back to my dorm in 2001, simply because the machine I had at home was faster than what the U had to offer. My (adsl) connection was 512kb/64kb at the time (may have been 128k up), and my applications ran flawless.
Any chance you had enabled MIT-SHM over your wan connection, or any one of the other X extensions that were really intended to only be used when client and server were on the same PC?
Re:So in other words (Score:3, Insightful)
*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
Wrong (Score:3, Insightful)
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.
Re:So in other words (Score:3, Insightful)
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.
Re:Windows and OS X versions, please. (Score:2, Insightful)
Re:Other performance gains (Score:3, Insightful)
It's obvious if you work with Microsoft products that VS and SQL Server, for some reason, get little-to-none usability testing, as opposed to virtually everything else Microsoft creates.
Well, as it happens, I work on Microsoft products - VS specifically - and particularly on common UI parts - main and context menus, toolbars, toolwindows, start page, switcher, options dialog, toolbox etc (though as a developer, not an UX/usability expert). So if you can point any specific usability flaws, shoot. Especially those in VS2010 betas.
I know quite a few myself; for example, our toolbar customization dialog (Tools -> Customize) is atrocious from UX perspective. But it would be interesting to hear outside perspective.
That said, it's not true that there's "little to no" usability testing and UI design review, for VS at least. I should know; I've fixed quite a few bugs that boil down to "this looks kinda wrong because there's an extra 1px spacing between icons here", or "keyboard navigation doesn't wrap around in toolbars with overflow" in this release cycle. And this kind of stuff has to be signed off with a dedicated UX team.
Is that seriously the best example you have? I'm starting to form a theory that most programmers have no eye whatsoever for detail... you're kind of confirming my suspicions.
Last version of Psi that I've regularly used was 2 major releases before the current one; I don't recall seeing that button there back then (or at least it didn't look as wrong as on the screenshot).
Also: the text selection highlight is wrong, it's supposed to be a dark blue background using my theme.
I've checked it out, and it seems to be wrong in the chat window output area (which is a custom rich text control), but all textboxes (which are stock Qt) use my system colors. So not really Qt fault here.
And HOLY SHIT, Control-C to COPY doesn't work! COPY DOESN'T WORK! COPY DOES NOT WORK
Again, chat output area - a badly written custom control. As you surely understand, it's just as easy to write one like that in raw Win32 API.