The DirectFB Desktop

= DirectFB Window Manager =

DirectFB (DFB) is may be the best way for developing graphic interfaces in embedded devices. X11/kdrive is not efficient enough and even if it was, its functional model is not adapted for embedded devices. This is not against X11, it's just that it's not the way to go for the embedded world.

The problem with DirectFB is that there aren't any frameworks for building apps on top of it, it lacks of a real Window Manager (WM). Therefore, we would like DirectFB to become the standard for embedded devices. The recently released WM SaWMan and its "testman" could be a good starting point, although it's not fully functional.

When looking at DFB code, the concepts of windows and WM are at the core. Instead, at the very core, DFB should only know of layers, surfaces, drivers and the like, then the WM layer should be present, and on top of it the concept of window would make sense:

DFB app |          v        windows |          v           WM           | v         DFB

The windows are a concept that has sense inside the WM. If an app doesn't want windows nor WM, they can be avoided because it'd be a shared library, so the app would have access to DFB as it is currently.

It's not that the current DFBWindow doesn't work correctly, only that the name "window" is not accurate in that context and causes confusion... the name DFBDrawable would be an adequate name.

The WM would be composed of two parts:

1. An upper part that talks directly to the apps and manage windows. So a GTK /Qt app, for example, would work exactly in the same way in X11 than in DirectFB. This layer would be equivalent to "testman" with a lot of new functionality.

2. A lower part that would be a shared library in charge only of drawing regions. It'd contain a list of all the elements that must be drawn by a given chain of drawing ops. This layer would be equivalent to SaWMan.

In order to make an efficient and high-quality graphics engine inside an embedded system, we intend to use the approach used by the Evas library.

From the Evas doc: "Evas is a powerful canvas. While most developers have used the Canvas widget of their favourite X11 toolkit, Evas is taking the canvas idea a huge step forward. It actually keeps track of what is rendered on screen. Unlike the usual canvas widget, Evas knows that you created a rectangle at a specific point on screen and it knows how to move it or resize it without having to rely on external data structures. Evas objects are essentially draw-and-forget objects. No need for the programmer to keep state. No need for the programmer to deal with redrawing and repainting. All this is gone. Evas is also highly optimized and can even run in embedded systems with constrained memory and low power processors. Apart from the X11 back-end, it also runs on OpenGL, Xrender, and frame-buffer devices". Evas is part of the Englightment project.

Thus, the proposed WM would fit in the DFB structure in the following way:

DFB app |                      v     -              windows |  (upper part, based on "testman") DFB |                | WM |                 v     |                 WM     -   (lower part with Evas, based on SaWMan) |                      v                      DFB

This is a work in progress. In fact, this is the first step.

Any feedback is welcome!