Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
GNOME GUI Graphics Red Hat Software Hardware Technology

GNOME Shell No Longer Requires GPU Acceleration 237

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."
This discussion has been archived. No new comments can be posted.

GNOME Shell No Longer Requires GPU Acceleration

Comments Filter:
  • by Anonymous Coward on Sunday November 06, 2011 @03:44PM (#37967480)

    Don't worry Gnome-shell is already slow. Terribly slow. Unbelievably slow. Unusably slow. I could give a load of other adjectives, but I think you get what I mean. The target devices (netbooks and tablets) usually can't handle it, and even proper desktops struggle...

  • by Anonymous Coward on Sunday November 06, 2011 @04:01PM (#37967614)

    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.

    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.

  • This is great news! (Score:3, Interesting)

    by Etherized ( 1038092 ) on Sunday November 06, 2011 @04:19PM (#37967750)

    I know there's a lot of resistance to GNOME Shell, but it's clearly the future of GNOME (like it or not) and the weird non-3d degraded mode that you get with GNOME 3 + no 3d is something that's not really fit for anybody.

    Personally, I really like GNOME Shell and I'm glad to see that it will be supported on older hardware. I always found the decision to completely ignore this hardware to be questionable and damaging to Shell's adoption rate (as if it wasn't going to have a hard enough time to begin with). Surely they could have provided a similar UX without the eye candy for older systems - at least now we have a workaround!

  • by jdege ( 88942 ) on Sunday November 06, 2011 @04:28PM (#37967830)

    Am I the only person who runs my desktops as often through remoting as sitting at the console?

    How fast will this be running over VNC?

  • by Anonymous Coward on Sunday November 06, 2011 @04:59PM (#37968058)

    Not the GP, but what he's saying is far more true to my experience than what you're saying. I don't think the GP's comment is spreading FUD, either, but just a truth that many GNOME'ers don't want to hear.

    Have you ever tried to use the GObject bindings for other languages? The Python bindings are the only ones that aren't terrible, but they weren't that good either. The rest were very incomplete, very outdated, or didn't exist at all. The theoretical benefits or capabilities of GObject are worthless if we can't use them in practice. I've had a lot more success with interoperability between Java, Scala, and Clojure than I ever have had with any GObject-based code. The same goes for .NET when the languages are C#, VB.NET and F#. Those all work seamlessly with almost no effort, while GObject needs a lot of hand-holding and even then it often just doesn't work.

    What the GP says about some C compilers not doing a good job optimizing unusual C code is correct, too. I used to work on a compiler that generated C for a proprietary OO language and this artificial C code confused the optimizers of several popular C compilers. We got much better performance when we wrote our own native back-end. So I could totally see some of GNOME's bad performance being caused by this.

    Also, KDE is very good evidence to back up the GP's claims. It's comparable in size and complexity to GNOME, but is written using C++ instead of C. On every computer I've ever used, KDE has been a lot faster than GNOME. It is also a far nicer environment to work with when you're writing code. OO programming is more natural in C++ than it is in C using GObject.

    Don't write off the GP's comments as FUD. There's a lot of evidence to show that they're real problems.

  • by thsths ( 31372 ) on Sunday November 06, 2011 @05:03PM (#37968080)

    Yes, but XFCE is getting pretty fat, too. It is no fun in a VM or on a netbook. In fact it is using compositing now, too.

    I have moved on to LXDE as lightweight system - it still uses a rather traditional window manager instead of an integrated desktop.

  • by Anonymous Coward on Sunday November 06, 2011 @06:58PM (#37968828)

    GObject or C++ or scripting language or whatever - function call overhead is negligible compared to all that work (and make-work) which a typical API function of a typical GUI widget is doing. When for other coders several years ago those same APIs, libraries and languages, and *worse* optimizing compilers, worked perfectly well on 10, and even 100, times less powerful hardware - trying now to blame other coders' ineptitude on GObject, GTK+, C compiler, X server, or whatever, is nothing but pathetic and idiotic.

    The tools may be imperfect, but writing good and fast code with them is perfectly possible - *if* a coder knows what he's doing. If GNOME authors wrote a slow monstrosity, it is their own failure and no one else's.

  • by segedunum ( 883035 ) on Sunday November 06, 2011 @07:51PM (#37969190)

    Is that an attempt at recursive humor?

    I don't think so because it's confirmed by your good self below:

    Presumably why they now have Vala.

    Yep, that's why they've tacked on another non-native language.

    AKA: Object Orientated?

    I believe the point is it's object oriented in the worst possible way.

    I certainly don't consider GObject/Gtk to be worse than QT or Apples API's.

    Uh, huh.

  • by badpazzword ( 991691 ) <badpazzword@gmai ... minus physicist> on Sunday November 06, 2011 @11:08PM (#37970162)
    I enjoy Unity and/or Gnome Shell. I'm the 1%
  • by msevior ( 145103 ) on Monday November 07, 2011 @01:07AM (#37970684)

    There is a hell of a lot of whining about GNOME 3 here. I'm a free software developer of desktop software (AbiWord). I personally like GNOME 3 and its approach to do a new take on how best to present a computer interface to users. I also maintain systems for my mother and daughter who are definitely not computer geeks. They're both impressed and comfortable with GNOME 3.

    So my extremely small sample imply that GNOME 3 is a good step. For the computers geeks out there there a plenty of alternatives. Find the one that works for you.

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...