gnome-tweak-tool [LWN.net]

gnome-tweak-tool

Posted Nov 11, 2012 12:04 UTC (Sun) by pizza (subscriber, #46)
In reply to: gnome-tweak-tool by deepfire
Parent article: GNOME 3.8 to drop fallback mode

Oh, you mean Doom 3, an eight-year-old game that was designed around the capabilities of the original XBox, with graphics hardware a full two generations older than your X800?

And the X800, also eight years old, is a full *seven* generations old now, and the last two (or three?) generations of even integrated Intel graphics is both more powerful and more capable.

Modern Linux Desktop Environments actually use the capabilities of semi-modern graphics hardware.

to post comments

gnome-tweak-tool

Posted Nov 11, 2012 22:21 UTC (Sun) by bojan (subscriber, #14302) [Link] (4 responses)

There is nothing wrong with running optimally on modern graphics hardware. The problem is that when non-modern graphics hardware or software rendering (a VM for instance) is used, Gnome 3 obsession with 3D gets in the way and makes the system unusable. And to do what? Animate overview?

gnome-tweak-tool

Posted Nov 12, 2012 2:46 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

In the real world, you have to make choices. A, B, and/or (maybe) C. Each has its set of costs, each has its set of benefits.

Only in la-la land (and Debian) is the answer "don't decide, and just go with all of the above."

"Running optimally" on modern graphics hardware means that you still have to support obsolete graphics hardware, which means your entire decision/design tree has to incorporate that. It's double to triple the initial amount of design/coding work, and exponentially increases the support cost, and does not gain them anything significant on their strategic long-term goals of building a kick-ass *desktop* environment.

They decided to focus their effort into building a single opengl-driven path. For a fallback for completely obsolete hardware, a pure software opengl rasterizer would be used, keeping the complexity at the natural component boundaries, rather than have to have the entire stack aware of everything else. It's sound software engineering practice.

We're at the same situation with desktop 3D as we were in the earlier days of Linux-wireless, before there was solid internal infrastructure and enough common code to make things consistent. Each driver had its quirks, so all applications had to know about those quirks to ensure consistent end-user behaviour.

NetworkManager was a major disruption, because its maintainer took it upon himself to actually fix the underlying buggy drivers so they all behaved in a consistent manner. This is where the Gnome3 folks are at now; a great deal of work is going on behind the scenes to drag the 3D stack kicking and screaming into the modern era.

This means prioritizing development effort -- fix the backend bugs, and everyone benefits in the end, rather than work around the backend bugs, and do three times as much work each time something new comes along.

(and as an aside, modern hardware doesn't even have any sort of 2D engine beyond a dumb framebuffer any more; do we "emulate" the old 2D stuff via the 3D engine, or target the future, and make everything 3D which vastly reduces the overall amount of work necessary?)

gnome-tweak-tool

Posted Nov 12, 2012 9:50 UTC (Mon) by bojan (subscriber, #14302) [Link]

And if there was no activities overview, opengl software rendering would be good enough for most stuff, even on a remote VM.

gnome-tweak-tool

Posted Nov 12, 2012 13:08 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

(and as an aside, modern hardware doesn't even have any sort of 2D engine beyond a dumb framebuffer any more; do we "emulate" the old 2D stuff via the 3D engine, or target the future, and make everything 3D which vastly reduces the overall amount of work necessary?)

I've been hearing that text-mode support and/or 2D support will vanish entirely from video hardware for ages, indeed this was why the framebuffer code was added to the Linux kernel in the first place -- some non-x86 platforms (e.g. famously Sun workstations) didn't have a VGA text mode and used a software framebuffer for everything (and with Sun workstations we learnt why that framebuffer should not be implemented in interpreted Forth).

But if you do that on x86, you break the BIOS. So video cards on x86 keep dragging around at least VGA text mode (and probably the whole panoply of even more ancient CGA/EGA/Hercules-compatible text modes and a bunch of VESA modes too).

Now you'd think EFI BIOS would give a chance to fix this -- only my new machine's EFI BIOS boots up in VGA text mode! So it doesn't look to me like VGA text mode is disappearing any time soon, and i fthat's not vanishing I suspect the 2D layer is sticking around too, even if in emulation, even if as merely a dumb framebuffer.

gnome-tweak-tool

Posted Nov 12, 2012 17:59 UTC (Mon) by drag (guest, #31333) [Link]

> I've been hearing that text-mode support and/or 2D support will vanish entirely from video hardware for ages,

Any part of the '2D acceleration hardware' has been gone for a while now. At least from modern hardware. Any sort of acceleration support based on 2D hardware is done through emulation, if it exists at all.

VGA mode and such things are more related to modesetting which is a bit orthogonal to that issue.

Modesetting issues were one of the biggest, if not the biggest, reasons to keep the old driver framework inherited from XFree86. Without modesetting support you couldn't really display anything useful on the display, especially if your display isn't one of the 'standard' resolutions and support for that resolution wasn't programmed into the BIOS (a typical issue on old pre-GMA Intel IGP laptops)

Now that mode setting has moved to the kernel rather then in the XServer having the Xserver direct access to hardware or their own special drivers is more of a detriment then anything else. Hopefully Wayland turns into a usable solution for running X applications on Linux since it will simplify the driver situation quite a bit.