Microwindows - Enabling graphical applications on embedded Linux systems

Why Microwindows?

In most embedded designs, the X Window System is overkill, especially when running a dedicated graphics application. For this reason, the Microwindows Project was developed. Microwindows is an open source project aimed at producing desktop-quality graphics functionality for small devices. The architecture allows for ease in adding different display, mouse, touchscreen and keyboard devices, as I will explain below. Starting with Linux version 2.2.0, the kernel contains code to allow user applications to access graphical display memory as a framebuffer, which ends up being a memory-mapped region in a user process space that, when written to, controls the display appearance. This allows graphics applications to be written without having to have knowledge of the underlying graphics hardware, or use the X Window System. This is the way that Microwindows typically runs on embedded systems.

Microwindows was designed to attempt to bring applications to market quickly, with a minimum of effort. In order to accomplish this, I felt that designing yet another graphics applications programming interface (API) would steepen the learning curve, thus discouraging interest and increasing time-to-market. Microwindows implements two popular graphics programming interfaces: the Microsoft Windows Win32/WinCE graphics display interface (GDI), used by all Windows CE and Win32 applications, and an Xlib-like interface, known as Nano-X, used at the lowest level by all Linux X11 widget sets. This allows the extremely large group of Windows programmer talent to be used in developing the graphical side of the application, as well as being familiar to the core group of Linux graphics programmers used to working with X11.

Microwindows runs in 50-250k of memory, an order of magnitude smaller than the X Window System. This is primarily the result of using a single routine for each of the drawing functions in the engine layer. The engine layer checks for clipping and calls a driver-level routine for drawing a pixel or line if unclipped. The X Window System duplicates the entire drawing routine for each pixel depth and has clipped and unclipped versions for speed. Microwindows fully supports the new Linux kernel framebuffer architecture, and currently has support for 1, 2, 4, 8, 16, 24, and 32 bits per pixel displays, with support for palettized and truecolor display color implementations, as well as grayscale. With both APIs, all colors are specified in the portable RGB format, and the system has routines to convert to the nearest available color, or shade of gray for monochromatic systems. Although Microwindows fully supports Linux, it's internal, portable architecture is based on a relatively simple screen device interface, and can run on many different RTOS's as well as bare hardware. This brings a big benefit: graphics programming by the customer can be shared between projects, and even run on different targets with different RTOS's, without having to rewrite the graphics side of the application.

Microwindows supports host platform emulation of the target platform graphically. That is, Microwindows applications for Linux can be developed and prototyped on the desktop, run and tested without having to cross-compile and run on the target platform. This is accomplished using Microwindows' X11 screen driver, where the target application is run on the desktop host and displayed within an X window. The driver can be told to emulate exactly the target platform's display in terms of bits per pixel and color depth. Thus, even though the desktop system is 24 bit color, it can display a 2bpp grayscale for previewing the target application. Since both the host and target are running Linux, most all operating systems services are available on the desktop host.

There are significant differences in the way that programmers familiar with using Microsoft Windows or the Linux X Window System implement graphical applications. Microsoft Windows programmers typically use Microsoft's Foundation Classes (MFC) C++ applications framework, or the newer Active Template Library (ATL) framework. Source code is provided for both of these interfaces, and both must use the Win32 GDI for all graphics drawing. Windows also includes quite a few user interface controls that are useable from the Win32 GDI, including buttons, listboxes, and the like. The X Window System, on the other hand, provides a low level interface known as Xlib, which implements low level drawing primitives only, and packages them up for execution on the display server. Most user interface solutions rely on "widget sets" implemented on top of Xlib, for modern functionality. We are working at porting some of the more popular widget sets to Microwindows, including GTK+/GDK, the basis of the GNOME project's desktop, and FLTK, a small C++ toolkit which implements quite a few user controls.