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)
> It's been called X-Windows for a long time. ... incorrectly. It's actually the X Window System.
http://en.wikipedia.org/wiki/X11
25% Funny, 25% Insightful, 25% Informative, 25% Troll
memcpy of 1000s of bytes is slower than sending a message. Many of these systems that provide direct access to RAM require lots of copying too. (OSX one example I'm most familiar with)
X11 also supports direct access to memory, but it is only used in very specific circumstances because it's extra work to set up.
“Common sense is not so common.” — Voltaire
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.
I guess maybe I'm making bad assumptions, as I don't really know what Chrome's intent with multiple processes is... but I think the answer to your question is no, it wouldn't necessarily impact security and certainly wouldn't fully negate the multi-process approach's advantages.
The major advantage to keeping separate tasks in separate processes, it seems to me, is that they have separate memory spaces. I can't sneakily inject code into another task's buffers if I'm not in the same process. In particular, if the browser spawns a process to execute some plug-in or whatever, there's less risk that the plug-in or whatever can trick the browser into executing malicious code. (Or cause it to crash, but that's more "stability" than "security".)
In other words, the biggest security risk comes from two processes sharing the same process at the same time. I don't think re-use is as big a problem. Sure, if you did a bad job of wiping buffers, then in theory one process could see its predicessor's data; and I guess there are scenarios where that could be an issue, though I'm a little skeptical that a malicious process would go rooting around its uninitialized space "just in case" it was handed a process with something it would recognize as sensitive data from a previous task...
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.
No.
Explorer is a cross between your shell and your window manager, its like the Gnome or KDE window managers except most of the window manager functions are the responsibility of process itself in Windows, although they are provided by the standard libraries, which us things like the uxtheme.dll and company to provide a consistent interface until the app goes well out of its way to do otherwise. You can use cmd.exe in place of explorer and apps won't notice the difference unless they interact with explorer, such as things that put items in the notification area (systray to most). Apps do not talk to explorer to display windows any more than apps on Linux talk to Gnome or KDE, or Finder on OS X. None of them have to be installed or work in order for Windows to be displayed. You can kill all explorer.exe processes in windows and you just won't have a start menu or clickable desktop until it restarts. You can not kill the X11 client and do the same, all processes using it will be disconnected and exit or crash.
Quartz is a toolkit/API used within the 'window_server', like DirectX to some extent on Windows. It is not the generic low level API like GDI is on Windows.
'window_server' would be almost the direct equivalent of X11 on OS X in native applications, if you exclude X11 for OS X, which acts as a translator basically between X11 servers (applications) and your X11 client (the gui you see) and passes that along to the window_server process to display.
In reality, all three of these systems use a different mix of the way these components interact and at which layer things are done due to their different designs. There isn't a 1 to 1 relationship between any of the components.
I do not recall which process on Windows handles the GUI, but it is more or less untouchable, unlike in OS X and traditional UNIX where you can easily kill the gui portion, doing so in Windows traditionally would result in a blue screen, this is no longer strictly true in the Windows 6.x versions (Win2k8/Vista/Win7), but I don't recall what process owns that part of the system off the top of my head.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
Windows does not have a bevy of toolkits to choose from out of the box.
Yet Windows developers often find the core Win32 API doesn't fit their needs, and waffle between toolkits like GTK, wxWidgets, Qt, and the usual cross-platform suspects. They also turn to .NET, Java (technically a whole language), MFC and others.
I constantly run into issues where I need to download a runtime to run a Windows app, because many developers don't simply develop for what is out of the box with a standard Windows install.
I've seen native X11 apps offer up checkboxes, form elements, and the like. So it is possible. It just doesn't look nice.
Developing audio on Windows is not necessarily standard, not easy. That is why apps might ship with their own separate audio library like OpenAL, tie into QuickTime, etc.
I have some non-trivial Windows apps that were built for Win95 that still run in Windows7.
Sadly, there were many Windows 95 era apps that were still 16 bit, which don't work in x64 versions of Windows 7. Half of my games (mostly from the XP era, not Win95 era) wouldn't work properly in Windows 7. Windows breaks compatibility all the time, even with service packs. Saying you have a particular app that still works doesn't mean the Win32 API has stayed the same, because it hasn't.
The GTK API has stayed mostly the same over the 2.x life-cycle. That is likely to change with GTK 3.
Now, I'm not a fan of GTK by any means. However, the GTK 2.x API has been around since 2002. Anything written for that API should still work fine today.
If they wanted the easy way out, they would have used wxWidgets, which at least feels native (by using the native toolkits) across Windows and Mac, and GTK on other Unixes.
That is basically what I said, except you apparently didn't get that. I suggested they use Qt (like wxWidgets is a cross-platform toolkit). Qt makes more sense for a variety of reasons, such as native bindings to Webkit (the heart of Chrome), and very easy audio development where you write code once, and then the audio works on Windows, Mac, Linux, etc.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
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
Uhhhh... have you seen Compiz, Beryl, Metisse, Gnome-Shell or any of the other whiz-bang screen-flipping and warping and cubing desktops? They do run X11 apps... through an X11 extension, be it AIGLX or XGL or something similar. X11 exposes whatever you want through the use of extensions, including the stuff needed to do 3D window manipulation. It did this when Vista was still Longhorn, let alone Windows come lately annex 7...
--frank[at]unternet.org
(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.
I'm dragging a Firefox window over a dead RDP session right now. It's erasing the contents of the window. I've never, ever managed to do that on MacOS X and not often on Windows Vista.
If I use a compositing window manager, that problem goes away, but in it's place comes a whole new set of issues. Ever notice how common "turn off Compiz/KWin compositing" comes up when people try to troubleshoot X issues? At least Vista is smart enough to turn it off for you when the situation merits it.
On no other platform do you ever have to think about syncing refresh rates. On X, you're at the mercy of the driver and window manager. On an nVidia card you're probably ok. On a recent Intel card you might be. On ATI it's a complete crapshoot. Throw in compositing and it gets even more complex.
Meanwhile, on much of the same hardware, you could run a hacked version of Mac OS X and not see a lick of tearing or artifacting.
I'm not saying that IRIX didn't do have that problem, but that, at the time, you could buy a commercial UNIX workstation and get a decently-integrated X server. The problem then was that you had to pay an astronomical sum to get the same window management performance that you took for granted on a Mac, and that a heck of a lot of tuning, testing and integration had to happen to get your (very expensive) video or 3D application to work, again, as well as a Mac.
Nowadays, you don't have to spend a fortune tog get decent X. What you have instead is that you're stuck with one card family (nVidia) or checking experimental code out of various git respositories, and even then you're not guaranteed the level of seamless video behaviour that you'd see on a Intel-based machine running Windows Vista.
I'm glad some people get decent X performance, but spending more than a little time on, say, Phoronix or Ubuntu's forums should disabuse you of the notion that everything works.
--srj/mmv
Comment removed based on user account deletion
If VNC is usable, you'll love NX. It is *far* more responsive for a given bandwidth/latency and it is persistent too (the session keeps running if your client disconnects.).
You can even run VNC to other machines through NX and it feels faster on limited bandwidth (NX creates a session on the Linux client that runs a fullscreen vncviewer to another system.)
It's my standard way of working remotely. My default work desktop lives on a Linux machine at the office and it resizes automatically depending on what screen size the client uses (as long as your Gnome or KDE version is recent.) Even at the office I run NX to my work session - over a LAN I can't tell the difference between local and NX.
thegodmovie.com - watch it
I'm dragging a Firefox window over a dead RDP session right now. It's erasing the contents of the window. I've never, ever managed to do that on MacOS X and not often on Windows Vista.
For RDP that makes sense- compositing doesn't happen over Terminal Services. What normally happens on Windows, is that when the Window Manager (not Aero) detects that an application has stopped responding to WM_PAINT messages, it actually swaps out the window for a special one that looks just like the last known good copy of the windows display surface. If it can't for some reason, it just dumps a plain white window with loading cursor instead.
That's actually intentional.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".