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?"
To be fair I think the gp meant Linux exclusive, not native. But even then Firefox is a pretty bad choice, since its development has always had Linux in mind as well as other platforms.
If you benchmark some random 3D games between Linux and Windows there is no Linux slow-down. If you benchmark the responsiveness of a well written GUI environment on Linux vs Windows, there's no slow-down. In fact, I've only rarely run into a situation where Linux is slower than Windows in a GUI or otherwise. The primary reason I've come to realize is lazy programmers writing slow client software, and in some cases, horribly inefficient GUI toolkits (Gtk, I'm looking at you).
X11 isn't the bottleneck, and ever since a few tweaks were done for desktop users, the Linux kernel isn't either.
- Michael T. Babcock (Yes, I blog)
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.
The problem is that when monitoring processes, people can "see" X11 using CPU cycles, whereas in Windows they only "see" the application doing. It's six of one, half dozen of the other -- but it makes it look like X11 is CPU-resource intensive. In reality, the same cycles are used for windows based apps (perhaps more? I certainly don't know...), but they look like the app using the CPU which is somehow more expected.
The thing is, X11 gets network-transparency essentially for free. The system requires some sort of inter-process communication, even when running on a local machine, and Unix-domain sockets are one of the fastest IPC mechanisms available short of shared memory (which is orders of magnitude harder to get right). X11 supports shared memory for local processes, to speed up communication of large objects like pixmaps, but the core protocol is socket-based and there is absolutely no reason to change that. So long as this is the case, why not support network transparency? BSD network sockets are interchangeable with Unix-domain local sockets once the connection has been established, so it's not like there's much more effort involved.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
VNC and RDP give you the ability to interact in an explicitly remote sense, the windows in question operate on the remote server instance and will remain in existence regardless of what happens to the local system.
That's one reason I stopped using X11 forwarding even though I could: If I lost connection on my laptop for any reason, every application I had open was dead. With VNC (or RDP), they were always running remotely.
Also, if I have an application open on display :0 I have no way (that I know) of moving it from :0 to :10 and having it appear uninterrupted on my local display.
I'd say that they're extremely useful hacks that solve issues that are, at least for me, unresolved in X11.
I've never had performance issues running X11 over a LAN.
VNC and RDP are useful hacks for systems that weren't designed for remote access, but they're no replacement for real network transparency.
Oh no you don't!
Try using X11 over something slightly slower as LAN. Just try it, over ADSL, whatever
I tried. And X11 is totally and utterly USELESS. A well configured VNC (and you have to really play with the knobs) is usable. RDP is the best (of course, it wasn't developed by Microsoft...)
how long until
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?)
No X11 can do Windows 7 and Vista and OSX expose features ... and does so .....
The whole point is that X11 does not draw Windows it draws tiles ... Window Managers draw windows ... and they can draw 3d glass dancing Windows on X11 without X11 caring about it ...
On Windows the layers are Driver - GDI - Application ...)
On X11 the layers are Driver - Kernel - X11 - Window Manager - Application (there may be more
The point is that you do not need to Expose the low level stuff to the application. .. just to the window manager, the application should not have to worry about redrawing itself, or resizing the window etc... it should let the window manager worry about that
Puteulanus fenestra mortis
(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.