Microwindows - Enabling graphical applications on embedded Linux systems
Microwindows Architecture
A key component in the design of Microwindows is to keep things small. Although this can sometimes preclude implementation of
more complex applications, the Microwindows design has distinct separation of driver level, engine level, and API level functionality so that,
if desired, complex functionality can be added on an as-needed basis without complicating the entire design. I'll discuss each of
these implementation levels in more detail.
At the lowest level, Microwindows abstracts a data structure for a display screen, a mouse or touchpad input device, and a
keyboard device. This structure appears identical on the top side, for use by the drawing engine, and includes code to interface with
the specific device the driver is written for. Microwindows includes drivers for quite a few different devices and operating systems,
with more being included with each release. Screen drivers for the Linux framebuffer include support for displays running 1, 2, 4, 8,
16, 24 and 32 bits per pixel, supporting palettized, grayscale, and truecolor display. The screen driver definition includes entry points
for reading and writing a pixel, drawing a horizontal or vertical line, and optionally, blitting memory from the screen to memory or vice
versa. By implementing only these basic entry points, all of the upper level Microwindows functionality, including TrueType or Adobe Type
1 font support, RGB colors, jpeg and bmp image handling, will run. If your screen device has hardware acceleration, or a peculiar method
of implementation in one of these areas, a modication to the driver is all that is required. In the same manner, touchscreen and
keyboard/button input is brought into the system.
At the middle level of Microwindows is the drawing engine. This code is device-independent, since all drawing is implemented by
calling a screen driver. The drawing engine presents a set of standard entry points for the API level above to call for drawing
functionality. The Microwindows engine abstracts an RGB color model for all colors, regardless of the physical display device.
Routines are provided that determine the hardware pixel value from an RGB triple, using the same interface regardless of whether the
physical display is running pallettized grayscale or truecolor. In addition, Microwindows implements all clipping at the engine
layer, using a fast, multiple-rectangle approach that allows for arbitrarily complex regions to be specified for drawing.
All font display is handled at the engine layer, including our new support for unicode-based TrueType fonts using FreeType, and
Adobe Type 1 fonts using T1Lib. Compiled in proportional fonts are also supported. The engine implements anti-aliasing using
alpha blending for smoother looking fonts on higher resolution displays. Currently, support for Ascii, Unicode-16, Unicode-32, and
UTF-8 encoding are supported.
The uppermost level of Microwindows implements one of the two supported APIs. At this level, the window abstraction is implemented,
which allow applications programmers to contain their display data in a full screen or overlapped window. This layer is also
responsible for event handling, and passing received hardware events such as touch screen or button presses to the application.
Next: Compile-Time Options/Summary