Proceed to WirelessDevNet Home Page
Publications, e-books, and more! Community Tutorials Store Downloads, tools, & Freebies! IT Career Center News Home
newnav.gif

Newsletters
EMail Address:



   Content
  - Articles
  - Columns
  - Training
  - Library
  - Glossary
 
   Career Center
  - Career Center Home
  - View Jobs
  - Post A Job
  - Resumes/CVs
  - Resource Center
 
   Marketplace
  - Marketplace Home
  - Software Products
  - Wireless Market Data
  - Technical Books
 
   News
  - Daily News
  - Submit News
  - Events Calendar
  - Unsubscribe
  - Delivery Options
 
   Community
  - Discussion Boards
  - Mailing List
  - Mailing List Archives
 
   About Us
  - About WirelessDevNet
  - Wireless Source Disks
  - Partners
  - About MindSites Group, LLC
  - Advertising Information
 
INDEX
>Introduction
>Why Microwindows?
>Microwindows Architecture
>Compile-Time Options/Summary
>Microwindows Screenshots
 

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
Sponsors

Search

Eliminate irrelevant hits with our industry-specific search engine!









Wireless Developer Network - A MindSites Group, LLC Trade Community
Copyright© 2000-2008 MindSites Group, LLC / Privacy Policy
Send Comments to:
feedback@wirelessdevnet.com