Slashdot Mirror
GNOME Shell No Longer Requires GPU Acceleration
An anonymous reader writes "The GNOME 3.0 Shell with the Mutter window manager no longer requires GPU acceleration to work, while still retaining the compositing window manager and OpenGL support. GNOME Shell can now work entirely on the CPU using the LLVM compiler via the Gallium3D LLVMpipe driver. This will be another change to Fedora 17 to no longer depend upon the GNOME3 fall-back, which is expected to eventually be deprecated and further anger GNOME2 fans."
The summary is a troll (as is typical for slashdot). Gnome 2 is still included in Fedora 17. The only difference is that if you have selected Gnome 3 for your desktop (which is default), and GPU acceleration isn't working, it will now fallback to unaccelerated Gnome 3 rather than Gnome 2. Regardless of your opinion of Gnome 3, this just makes sense; it would be much more confusing to get a completely different desktop than you were expecting just because your video drivers got borked. Not to mention it is wasteful to have to install Gnome 2 as a fallback if you want to use Gnome 3.
GNOME is a perfect study in how not to architect a software system. Everything about it is wrong.
The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C. Everything about GObject is stupid and counterproductive. It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place. Worse, this sort of code promotes library design that's slow and inefficient. To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.
Nonsense. GObject gives you multi-language bindings for free and if you're just an application developer it only makes your life easier. You can develop GNOME programs in C++, Python, Java or whatever suits your tastes.
I don't think the overhead resulting from using C is substantial at all. Maybe you get more overhead than C++ by always using virtual calls but that is offset by not doing C++ magic like unnecessary constructor/destructor calls. You'll have to back this up if you want me to believe you.
It basically goes totally downhill after that. This bullshit with GPU acceleration being required in the first place, and then this additional bullshit involving LLVM, is yet another in a long list of flaws and horrible decisions.
I encourage all of the developers that I mentor to use GNOME and to get a good look at its internals. I just make sure that they know not to do what GNOME has done. By seeing the mistakes firsthand, it's less likely that they'll repeat them in the future with the software that they create.
I'm not a fan of GNOME and I agree that they are headed in the wrong direction, but the problems are not at all due to GObject or C. Cut the FUD when you criticise GNOME next time.
Note that compositing != GPU acceleration. Mac OS X has always used compositing, but it was entirely software. There are still good reasons to do so. I'll compare for you:
No compositing, one frontbuffer: You don't get your own pixmap to draw onto. You have to send drawing commands to the display server to draw on your behalf, to prevent you from drawing wherever you want on the frontbuffer. Unfortunately, if you have something complicated to draw, the user gets to watch as the drawing happens. When drawing a new object, generally the algorithm used is to draw the background, and then draw the objects in order from back to front. This means whenever the screen is updated, the user will see flicker whenever any objects are updated because they may briefly flicker to the background color. To work around this most modern toolkits (Qt 4, GTK 3) render to a pixmap, and then just tell X to draw their pixmap when they are done. This avoids the flicker but uses a bit more RAM.
With a compositor, the application still draws to the pixmap, but instead of requesting the X server to immediately draw their pixmap to the screen, they pass it a handle to the pixmap and the display server can draw it whenever. This makes a lot of things easier, like vertical sync and effects, as well as things like color format and color space conversion.
Drawing the pixmap on the screen is really the same operations, no matter if compositing is on or off. And the API your compositor uses shouldn't matter too much either if the underlying implementation is optimized. The highly optimized Gallium3D blitter is going to just as good as the traditional X blitter, if not better. The only thing slowing it down in this case is the fact that OpenGL API is rather overkill for blitting, but hopefully the llvmpipe backend is optimized for this use case. And it's probably not worth it to make the compositor support two drawing APIs, like KDE, as they both end up doing the same thing anyway.
It's about time Slashdot stops accepting 'blogspam' links, such as Phoronix, instead of attributing the actual source itself. Phoronix didn't solve this, a developer did.
A badly written Slash summary (and 'article') which just links twice to the same braindead Phoronix article (which itself is a several day old duplicate) is bad. Very bad.
Dredged from the bottom of Phoronix:
Mailing list post: http://lists.fedoraproject.org/pipermail/devel/2011-November/158976.html
Fedora 17 feature point: https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering
Personally, I have little doubt that the "anonymous reader" is Michael Larabel himself.
"A Goddess rarely smiles for she is forced by others to be an island unto herself." - Zephiris
Who says it's not a verb? The Oxford English Dictionary lists it as having been a verb since at least 1818, and as being more specific than "design".
Quidnam Latine loqui modo coepi?