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?"
"Has the design of X11 withstood the test of time better than people tend to give it credit for?"
Yes of course it has. X11 is great and anyone who thinks otherwise doesn't understand it properly, or have an accurate idea of what it's genuine problems are actually due to.
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
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.
I'm pretty sure that the biggest slowdown for Chrome isn't the memcpy/bitblitting for the display - it's probably something to do with the insanely big history files it generates as part of it's searchable history.
Files you can't limit in size, can't compress, can't optimise. Instead all you can do is to delete them and loose all your precious history information.
It also has the bonus of providing a searchable address bar that performs significantly worse than firefox's searchable address bar !
I use both firefox and chrome simultaneously at home and at work, dedicated each browser for different tasks I do. It's a real shame that Chrome is being seriously degraded over time by this fault - I've started switching back to firefox because of it as my laptop just struggles too much with it now...
X11 is not bloated nor slow, GTK is both. Put 100 or so spinedits on one form in Win32 and in GTK. On netbook or anything other than quadcore machine, you will see significant difference in speed. And it is not because of the graphics. Sometimes I think GTK render fractals somewhere just to keep processor busy. Meanwhile, when I draw 100 spinedits using only cairo, it is almost as fast as Win32 while giving the same output as GTK including shadows, gradients, etc... I've being noticing this GTK behavior since forever.
GTK folks, please fix it.
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.
Give the guy a break. He's only trying to create synergy among web-enabled paradigms.
Funny, but the real answer is GDI.
http://en.wikipedia.org/wiki/Graphics_Device_Interface
Buckle your ROFL belt, we're in for some LOLs.
"For whatever reason, Linux drivers have NEVER taken advantage of this, and that is why Linux often looks clunky compared to Windows on the same hardware."
This is just BLATANTLY WRONG.
All you need to do is read the feature announcements for the nVidia and ATI display drivers, which you apparently DON'T DO.
nVidia's REAL target market is the folks who work at animation companies, and the hard-core data visualization people. Their products are designed to fly in THIS environment. This market is VERY HEAVILY tilted toward Unix. That is WHY you can get such EXCELLENT display support under Linux. The rest of us are just piggybacking off of this.
Because, from a user's perspective, it doesn't work all that well. Here's an example:
On MacOS X, it's just about impossible to get into a situation where a) video tears or flickers, or b) menus and windows can "rub out" other menus or windows (eg, you can't drag a window around like a giant eraser on Mac OS). On X+whatever, it's pathetically easy to do either. Windows is somewhere in-between the two.
To be fair to X, managing compositing et al isn't it's job---but it should be! Between X's by-design paucity of features and the number of combinations of video driver, X server, window manager and settings thereof, it's hard to get a decent, modern desktop experience. Had X been designed a little more smartly (eg, for actual people and not for computer scientists) this probably wouldn't be such a problem. Grafting things like multiple display support, accelerated 3D, video playback and now, compositing, have shown problems. Back in the day, when you could just buy IRIX (ro whatever) and be assured of a working, end-to-end X implementation this wasn't an issue. With the clusterfuck that is X.org+DRM+GEM+Mesa+KMS+GL/GLX/AIGLX+DRI/DRI2+UXA/EXA/XAA+whatever window manager is invovled, it's a crapshoot.
By comparison, again, we have MacOS X's system, which again just works, even if in theoretical terms it's a little slower. Users don't care that much about GTK benchmarks; they do care if the user experience breaks down.
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.
--srj/mmv
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
Let's just say you're wrong and I've seen flickering on plenty of Mac OS desktops.
And with X11, the flickering you get is more likely due to the program ignoring X backing store and "doing their own thang". Well guess: their failure isn't the fault of X11, is it.
"To be fair to X, managing compositing et al isn't it's job---but it should be!"
Compiz: It IS!!!
Sheesh.
And Enlightenment had compositing freaking YEARS ago.
" Between X's by-design paucity of features"
You mean like C's "paucity of features" that means libraries that do whatever you damn well want?
There is no "by-design paucity": by design X11 is extensible. See X extensions.
"Had X been designed a little more smartly (eg, for actual people and not for computer scientists) this probably wouldn't be such a problem."
Uh, what design WOULD have been for "actual people"? This statement, bald as it is, makes no sense.
X11 is designed for the task it has to solve: drawing a GUI.
One program: one purpose. Expose capability and don't impose process: someone may think of a use you never considered when writing it, so don' t write a program that will hate them for it.
The UNIX way.
Which, oddly enough, Apple have embraced to a large extent since bringing out Ten.
"By comparison, again, we have MacOS X's system, which again just works, even if in theoretical terms it's a little slower."
Two problems: the dissing of X is how slow it is. So Ten's system being slower should be more dissed, yes?
Secondly, ten's system doesn't just works else there would be no problem with "But Mac can't support clones, they have to have a limited selected hardware to deliver the eXPerience!". Ignoring that this just works meme is wrong. I've seen it often just stop a lot.
"The UNIX Hater's Handbook, which is a little bit out of date now, goes into the design errors of X "
And here we see where you've been misled.
The UNIX paradigm is extensibility. Policy is set by the use of the program. not by its programming. And the UNIX haters hate UNIX so hate the UNIX paradigm. Ergo they hate X too.
Maybe they're just a little bit predisposed to a priori conclusions...
And it's not the "why does X drive people nuts" it's why do people get a stiffy when the opportunity comes to diss X?
(oh, and a quick look at that, hmm, *discourse* seems to be a person who gets a real big boner over getting to rant and rave about how X is teh devil. Could he be any less coherent?)
(and "client" and "server" roles were reversed from convention, for some strange reason)
What? Since when? I always thought that the X server was the behemoth application that ran, waiting for connections from other apps (the clients), consolidated the requests, acted on them, and responded back to those clients. You're telling me that X itself is termed the client, and those little apps that all connect to it are called servers? Yeah, that IS backwards!
Oh, hold it, that's not what you're saying at all. You think that "server" is a designation of the size of the machine it runs on, not a designation of the model of communication the application itself uses. You do realise, though, that even a "web server" (which could just be a wall wart acts as a client for DNS querying, right? That "client" and "server" are fluid terms based on what the app is doing, and not where it is?
A server responds to incoming request(s), usually from multiple sources. A client initiates those request(s), usually to a single target. That is all. X uses these terms perfectly. The application sitting on my desktop machine is the server, and the xterm I'm running on the Linux/zSeries box is the client. For this particular purpose. Of course, that Linux/zSeries box is also the ssh server that I use to connect to it in the first place, over which a tunnel is created in the reverse direction to allow that xterm to come up at all. It's not the convention that is being ignored. It's just that you're using the wrong definition.