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 Chromium on Mac? (Score:4, Interesting)
Does anybody know if it's possible to compile a version of Chromium for X11 Mac?
Re:Windows and OS X versions, please. (Score:1, Interesting)
No. It's MacOS 10. OS X is just stupid intentionally confusing terminology.
We already had a GUI called X. It was around for about 20 years before Apple decided to start it's Microsoft-esque nonsense.
Re:Windows and OS X versions, please. (Score:4, Interesting)
Uh. Maybe you don't understand what I am saying....
I KNOW that MacOS 10 is OS X.
I'm asking if anybody has compiled a version of Chromium to use X11 instead of using Cocoa.
So in other words (Score:3, Interesting)
So in other words, those who programmed on X when X was the only big player are now older where you lose hair and sexual virility.
Colour me surprised.
Meanwhile X is still working better than Mac or Windows as a GUI framework.
Thing I don't get is why so many guys have a hard-on for dissing X.
Why?
Comment removed (Score:3, Interesting)
Memcpy not the biggest problem for chrome/chromium (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Re:X11 has never been a problem. (Score:5, Interesting)
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.
Yes, exactly. X11 ran reasonably complicated applications 20 years ago on hardware that we throw out as woefully inadequate (or quaintly archaic) today, and did so with entirely acceptable speed. X11 isn't the problem -- hardware is what, two orders of magnitude faster now? -- it's all of the poor programming practices that have layer upon layer of abstraction and interpretation stacked tall and high.
I had a 266 MHz laptop in the mid 1990s (about 15 years ago) that ran Linux (RedHat 6.2, mostly) and X11 perfectly well with a mere 64 MB of main memory. A while ago, I tried to load a Fedora release (9, if I recall correctly) on it. "Laughable" is a good term to describe the result. My current laptop has a 10x faster processor and 50x more memory. There's more cache on the processor in my new laptop than total system memory on the old one --- And yet, Fedora 11 feels sluggish on the new hardware. X11 is not the problem.
Chrome - Webkit - KHTML - Linux (Score:1, Interesting)
Maybe it's because Chrome is based on Webkit that is based in KHTML that was developed mainly on Linux
Re:Hold the phone (Score:1, Interesting)
Yeah. As opposed to tests made by Microsoft and Apple paid "impartial and reliable" entities.
\sarcasm
Read this yesterday, installed, then removed. (Score:3, Interesting)
What to make of X11? (Score:3, Interesting)
I'm wary of any real old legacy code.
I also know that graphic displays and inputs are vastly different today than they were 10 and 20 years ago.
Do I know that X11 is inefficient? No, but I sure read plenty of other people making those claims. However, I suspect that X11 wasn't developed initially with today's needs in mind. I do know that the X team keeps promising features, cutting them, and then still shipping six months past their projected release dates.
Novell has guys working on Mono, Evolution, OOo, KDE, Gnome, the kernel, etc. What I don't see a whole lot of is major distro companies (Red Hat, Novell, Canonical) paying for major upstream development with X. Maybe it just needs a little more love, some deprecation of old cruft, and a new forward-thinking design. There seems to be somewhat of a future direction (GEM, DRI2, MPX), but perhaps X needs a revolution.
Is Wayland a step in the right direction?
What to make of ignorant flamebait? (Score:4, Interesting)
"I also know that graphic displays and inputs are vastly different today than they were 10 and 20 years ago."
Really what is so different other than the number of pixels on the display?
"I suspect that X11 wasn't developed initially with today's needs in mind."
Then perhaps you should read about the original goals of the X window system.
Re:Choosing the correct abstraction layer (Score:2, Interesting)
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.
I'm not sure that's how I would characterize java myself. Something like this is closer to the mark: A mediocre design made optimisation of the VM rather hard (particularly in the face of concurrency). However after many years and some heroic effort, VMs are now available which can mostly mitigate the poor designs and perform well.
Re:It's Chrome OS (Score:3, Interesting)
No - ChromeOS is looking to be an actual honest to goodness OS built around the Linux kernel with a Google-developed graphics subsystem. They are mainly targetting it towards running their own web applications rather than bundling apps with it as is the case with most other OS's, so the only INCLUDED app might be Chromium, but all indications are that developers will be able to write/port other applications to the system if they desired.
Personally I'm interested in seeing it. It's just an opinion, but most Linux distributions just have far too much legacy code and ways of doing things stacked on top of each other these days. I want an open source OS, but I think we kinda need to toss out a lot of what we currently use and start anew. Unfortunately it's not easy to do that without commercial backing, but Google pushing such an effort would really help things along.
Re:Memcpy not the biggest problem for chrome/chrom (Score:3, Interesting)
With all due respect, it sounds like you want to blame everything negative about Chrome on one feature you don't like. Just sayin', the developers might have a reason to think that the rendering speed has something to do with the windowing system - they're a lot less likely to be just guessing and calling their guess "pretty sure".
But for the sake of argument - if the history files are the big slow-down for Chrome, why is that slowdown less pronounced on the X11 version?
Uninformed and wrong (Score:5, Interesting)
"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.
Re:X11 has never been a problem. (Score:5, Interesting)
I've never had performance issues running X11 over a LAN. VNC, on the other hand, is noticeably sluggish (RDP seems to work well though). I don't run apps over a WAN very often, except for the occasional emacs session (which is a bit laggy but useable).
But more importantly, the X style of remote access is much, much more useful than VNC/RDP. Remote apps integrate seamlessly into my desktop, instead of being stuck in a separate window. And multiple people can run remote apps on the same machine, without interfering with each other or a user who's physically sitting at the machine.
VNC and RDP are useful hacks for systems that weren't designed for remote access, but they're no replacement for real network transparency.
Re:So in other words (Score:5, Interesting)
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 [art.net]. It's worth reading if you're wondering why X drives people nuts.
Re:Other performance gains (Score:3, Interesting)
Windows does not have a bevy of toolkits to choose from out of the box.
Windows has, the Win32 API, GDI and the common controls. They come with EVERY install of Windows, it is a requirement. Pretty much everything else sits on top and is optional. You can draw buttons, checkboxes, ect, that work across all apps the same with nothing else. You can add a layer of abstraction with MFC and ATL if you want, but most developers who have been doing it for long enough will avoid those as they are more trouble then they are worth.
OS X has Cocoa, Quartz and some other APIs, same thing, included out of the box, required, and consistent.
Linux or more accurately, X11, doesn't. You need GTK, or QT or SOMETHING if you want a widget set rather than coding your own buttons and UI interfaces using the raw X11 API and a bunch of pixmaps. You HAVE to use GTK unless you want to design your own controls, and have no consistency with other applications. X11 does not include any common set of controls. And like it or not, GTK is crap. Qt is definitely a step up, but they hung themselves with their retarded licensing moves over the years, and GTK took over, sadly.
OS X has a standard audio interface.
Windows has a standard audio interface.
Linux does not, hence all the bitching and complaining done by more than just the Chromium people about audio in Linux. My recent looking into MythTV shows this.
No one wants their windows app to look like Qt. Mac users most certainly don't want Qt.
If it takes a bunch of work to 'retrofit' GTK 3 into apps, then once again, you have another reason why Linux app development is not worth the effort and something to bitch about. I have some non-trivial Windows apps that were built for Win95 that still run in Windows7. Outside of hello world, that is not true with GTK, hell, a Hello World app written for GTK won't even run any more on Linux since there have been several changes to things like vtables in the compiler.
I have the distinct impression that neither you, nor the people who modded you insightful have dealt with developing for a consistent OS before. You have, inadvertently I'm sure, just pointed out why most commercial software developers don't target Linux. Too many choices can be a bad thing. The changes to get most Windows or OSX apps to work on the next release are trivial, and you've usually known about them for the last 2 major revisions at least.
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. They did not. It probably wouldn't provide them with a low enough interface to do what they wanted to do, and now we're back to bitching about the lack of a standard toolkit on Linux. The two linux machines I have do not even have GTK installed. This of course is not Linux specific. My FreeBSD boxes are the same way. A few have GTK because they have some GTK apps installed. Some have Qt. Some have both, one has neither, no X at all, but thats a different story entirely and not really the point.
Re:Choosing the correct abstraction layer (Score:5, Interesting)
X itself is undergoing incredible levels of development and improvement. Way back when, "The Open Group" tried to say that X was "complete" with X11R6, and no more development was needed, though somehow defects and omissions let numbers start creeping in after the decimal point. IIRC it got to somewhere in the X11R6.3-X11R6.5 range. Then XFree86 took over, ramping up some innovation, though still slower than many liked. After that X.Org took over, decided it was high time for X11R7, (They did X11R6.9 as a stage to get there.) and things started moving faster.
At this point, they're redrawing the lines (KMS, DRI/DRI2, DRM) between kernel and user space to (hopefully) get a better balance speed and stability/security. They've pretty much reworked the 2D acceleration (*XA) and are reworking the 3D acceleration (Gallium3D) which will also simplify driver development. The inteface has been reworked down near the protocol level (xcb) to improve speed and memory usage. One thing I've heard talk of is "inverting" the stack to put all primitives on top of the 3D hardware, since that's where most of the hardware performance work has been done.
The next 6-12 months will be very interesting for X-Windows, but then again, the past few years have been interesting, too.
Re:X11 has never been a problem. (Score:3, Interesting)
The modular nature multiplies the number of potential bugs by an order of magnitude for each layer. I.e. if the Client/Server model of X11 were merged into simply the X11 renderer, GUI applications would be an order of magnitude easier to write. It isn't too bad for X11 because it isn't that big or all that complicated, but the client/server nature of X11 creates the potential for a lot more bugs.
The biggest example of the bug problem with modular systems is the GNU HURD kernel. It is modular, I believe it has 4-5 parts that must work in unison to function, and in 20 years Stallman and his group have yet to produce a working kernel. Compare that to Torvold's Linux kernel, which was integrated and took a couple years to develop pretty much by himself.
Part of the problem with X11 is that it is NOT a complete package - it's the "last mile", so to speak, and you need three or four more layers to get a modern desktop. If you make an honest comparison of a complete desktop package based on X11 that matches Windows Vista/7 or Mac OSX and there is no question as far as quality. The X11 based setup is harder to use and generally less useful than the Windows or Mac counterparts. Incidentally, I've used OSX the least but found it the easiest to pick up - good design counts.
Vive la X (Score:3, Interesting)
I've noticed that X unfortunately gets a lot of metaphorical rotten vegetables thrown at it from Linux users; even people who apparently are fans of Linux in every other respect.
In my own opinion, however, X qualifies as one of the greatest pieces of software ever written. Put it in perspective, here; the system has been in continual use and evolution since 1984. That's 25 years this year. Granted, its' configuration process in particular has needed radical reform, and fortunately it has recently got it.
I don't understand why people criticise its' stability, either; for me it has always been rock solid, particularly on FreeBSD.
I'm also not really surprised that Chrome might run faster under X than under Windows or the Mac. If there's one thing that's always been true of UNIX in general, it's that the system doesn't include unnecessary frills. When you're wanting to be optimised for speed in particular, that can only be a good thing.
I love X.
Re:So in other words (Score:1, Interesting)
It must be me, but I seem to have that problem on every OSX machine I've used to date (upto SL) on a trackpad or mighty mouse...
Re:So in other words (Score:3, Interesting)
I think we said that: if you use Compiz or KWin, you don't get rub-out because all this is composited off-screen. (you might get tearing, if you don't have the right card and/or haven't precisely set up sync-to-blank). That's great.
Now, if you turn on Compiz/KWin, you break tear-free video playback on some cards/drivers/versions. You might also break display of accelerated 3D in a window. That's not so great.
Those of us who are complaining about tearing have probably forsaken Compiz/KWin+Compositing because we can stand a little rub-out versus video playback being shot. That you have to do this at all is kind of problematic, and the WORKSFORME (or, "get an nVidia card") attitude doesn't help. Even casual perusing of, say, Phoronix should tell you that this is a problem for a lot of people.
Re:X11 has never been a problem. (Score:3, Interesting)
Random tip: if you just want to run a single app from the remove machine, ssh -XC :-)
The X tells ssh to forward X and the C means compress. One particular app I used to run (connecting from anywhere to my Linux box at home, which was behind a 256k up DSL) launched in 30 seconds with -X and 10 seconds with -XC.
Of course, different people's definitions of "usable" differ.
Otherwise, I hear good things about http://freenx.berlios.de/ [berlios.de] .
Re:So in other words (Score:3, Interesting)
It is an afterthought in that it is stacked on top of the rest of the system rather than integrated
Which, of course, is precisely why it has been able to survive, whereas display systems embedded in other platforms died with that platform.
It is perfectly aligned with the best practices of unix, and a design largely retained by OSX (as if that confers any special blessing).
There are as many performance gains to be realized by this method as there are drawbacks. With the advent of high performance GPUs, its only a matter of time before the entire X server is moved into the hardware on the video card, (where some say it belongs). Such compartmentalization would be harder if not impossible if it were embedded in the OS.
You are also correct that any criticisms of the past are largely without foundation with current x servers, it has been optimized and extended more than any other component of the unix ecosystem.