Whitepaper On GTK+ For Linux Framebuffer

yuggoth writes: "LinuxDevices.com features a whitepaper about the upcoming GTK+2.0 support for the Linux framebuffer, which was mentioned on /. some weeks ago. Thewhitepaper describes architecture, benefits and limitations of GtkFB and also compares GtkFB with X based GTK+." Only one word for this: Sweet!

Comments

Re:Ummmm...duh?

[Ian Bicking]

GGI isn't actually a hardware interface. It's a userspace library that abstracts the hardware some (similar to Xlib in some ways). It can run ontop of several different actual display devices -- KGI (primarily Linux -- though I heard that FreeBSD was considering using it more mainstream), X, or framebuffer.

I think you use a different library -- dynamically linked -- depending on what the display is, so that GGI should be fairly lightweight when most of its features exist on the target display, i.e., it reduces GGI calls to Xlib calls when as possible, and with KGI it passes as much on to the graphics card as possible. I guess this is similar to Open GL.

The framebuffer doesn't do this sort of optimization much, and I don't think it can do much of it because it has an interface that is more primitive than the actual device (graphics card) that it displays on. At least, this is what I understand. GGI on the framebuffer is very slow -- but probably just like GTK on the framebuffer will be fairly slow.

Another approach

[Animats]

Maybe it should work like this:

• Each window appears as a framebuffer device. Applications can either write the framebuffer directly, or use OpenGL on it.
• The front window runs with top priority. Application writes to it take effect immediately. It may be a mapping of display memory if the hardware is suitable.
• All other windows are really offscreen bitmaps. Applications write to them, and the window manager copies them to the screen when they change. Updates can be a second or two behind. All clipping is done during this copying.
• Applications don't have to worry about window clipping, damage, or redraw. Drawing, widgets, etc. are part of the application, not the window system. All the window system knows about is rectangular bitmaps.

This is far simpler than classic window systems, which are a legacy from the days when we didn't have enough RAM to represent all the windows at once. There's a clear upgrade path from the current "framebuffer" approach to a window system like this.

Single process?

[infiniti99]

Of course GtkFB has limitations too. The main limitation is the single-process model. All code in the system must be in the same binary and run in the same process. This means you can't use processes to separate and protect different parts of the system from each other. It also makes it harder to design larger systems.

This is a pretty serious limitation. I didn't see any mention of a future change in the whitepaper, but there definitely should be. How else would this be useful if you can only run one big "master app" ?

I've used Qt/Embedded, and it works by starting up a host app (any app can be a host) which initializes the display and proceeds to run. Any Qt/Embedded apps to get launched from this point on will use the host's framebuffer.

For now (toolkit preferences aside), Qt/E will probably a more viable solution for handhelds, since it's A) Done, and B) has a good environment host application.

GtkFB sounds promising, but it absolutely needs separate process support. I don't think I missed anything about this in the whitepaper. Can anyone shed some additional light on this issue?

-Justin

Instead of focusing on these features, GTK

[Bob Dobbz]

developers should instead look into some of the problems the toolkit is currently facing.
One of the biggest problems is lack of "accessibility" features. Just try using any GTK app without using a mouse. Impossible, most of the time. Implementing accessibility features (menu shortcut keys, etc) is placed on the programmer, instead on the toolkit designers. There are numerous bugs and misfeatures when it comes to accessibility features in GTK.
One perfect example of this is "The Gimp" program, which cannot be operated from keyboard at all. None of the menus have "hotkeys", there is no keyboard shortcut to bring up "the menu", and once the menu is up, it's impossible to navigate it except using cursor keys, which is much slower than if all the menus had hotkeys assigned.