Chapter 4. 15h00 - TWIN: An Even Smaller Window System for Even Smaller Devices

After all the fancy hand-waving talk from Jim's presentation, Keith got up and gave us something real we could sink our teeth into: TWIN, an incredibly small window system for small devices. Basically he was working on a project to bring a decent GUI environment to devices with 8MB flash, under 1MB of RAM, but a decent amount of processing power (in the 200MHz range).

To play with TWIN and give it a whirl yourself:

$ cvs -d :pserver:[email protected]:/local/src/CVS login
[hit enter when it asks you for a password]
$ cvs -d :pserver:[email protected]:/local/src/CVS co twin
$ cd twin
$ ./autogen.sh
$ make
$ ./xtwin
       

So how constrained of a device are we talking about? Well, all that we need from the hardware is a block of memory that acts like a framebuffer into-which we can poke bytes which turn into pixels on the screen. Given these constraints it would be logical to assume the API is rather constrained too; that would be completely wrong. Keith didn't want a device with a difficult API so he took Cairo, Xrender, and X and stripped them down to their bare minimums. Of course not all the functionality of all these systems are all available, (only simple drawing operations (2 operators) are available) but from these simple operations just about anything can be done. The result is an alpha-blended GUI environment with scalable, proportional text that is surprisingly full-featured given the constraints.

One of the biggest constraints in this device is the fact it doesn't have floating point so all floating point operations have to be emulated. For this reason the drawing routines drop floating point as soon as possible.

Another side effect of this constrained environment is the removal of the event queue. A lot of processor resources are required to maintain and manage this queue so TWIN doesn't bother with it. All events are dispatched immediately.