Go to the Xtreme home page!

Go SourceForge!
Hosted by SourceForge

Docs & Info
About...
License
Paradigm
Tutorial
Reference
FAQ
Who uses it?
Old Announcements
Get It!
CVS
Download/Install
Get In Touch
Bugs
Discussion Forum
Mailing Lists
Support

Xtreme - Paradigm

There are many approaches to graphics programming:

Simple but Limited: BGI

The simplest ansatz is used by Borland Graphics Interface (BGI): it offers a set of commands for "drawing primitives" like lines, pixels etc. BGI is very intuitive to use, but it's not very powerful: neither does it provide mouse support, nor multiple windows. It is also locked to the ancient DOS platform.

Imperatively Inconvenient: Handles and Events

A more powerful approach is taken by (X) Windows and OS/2: multiple windows are possible by facilitating "handles" and associatied graphics contexts, which are used for the actual drawing. Depending on the individual quality of the interface, this kind of graphics programming is more or less convenient.

It turns out that for beginners, events are a major stumbling block. Events are used to manage input from the window (mouse clicks, key strokes) and window commands like redraw and resize. The main program consists of an event loop, the program flow is completely opaque.

Object-Oriented: Hidden Handles and Events

Today, the most popular method to deal with windows are class libraries. Mostly written in C++ or Java (or maybe C# in a few years), examples of such class libraries include Troll Tech's Qt, Inprise' Object Windows Library (OWL), the Microsoft Foundation Classes (MFC), and Javasoft's Abstract Windowing Toolkit (AWT) and Swing classes. These libraries offer class hierarchies for drawing, convenient dialog design and more. Inheritance allows for powerful customizations.

Events are hidden behind chains of responsibility or similar patterns; however, the program flow remains opaque.

The Stream Ansatz

The Xtreme paradigm is fundamentally different. The basic concept of Xtreme is the data stream. Graphics primitives like lines are streamed into the window, and key strokes and mouse clicks stream out. A window is treated like a file, or more precisely: like a C++ stream, like cin and cout. Text or graphics objects are written into the stream, and key strokes are read from it; multiple windows can be opened at the same time just like multiple files can. Here's an example:
#include <unistd.h>  // for sleep()
#include <xtreme>

main ()
{
  int i;
  // open a 200x200 window, title "Hello World"
  xstream xs ("Hello World",0,0,200,200);
  // write some text...
  xs << "Hello World!\n";
  // a green circle...
  xs << Circle(100,100,90,Green);
  // a yellow rectangle...
  xs << Rect(5,5,195,195,Yellow);
  // prompt for input
  xs << "Please enter an integer number: ";
  // read input
  xs >> i;
  // write some more drivel
  xs << "\n   you entered " << i << "\n"; 
  // wait for 5 secs, so user can see the window
  sleep(5);
  // window is closed when it leaves scope and is destructed
  return 0;
}
	  
The central element of Xtreme is the class xstream, which represents a window stream. Basically it can be used like a file open for both reading and writing.

Screenshot for above example

Advantages and Weaknesses of Xtreme

The stream ansatz is definitively not the panacea. In fact, it's usefulness is limited to a rather narrow set of applications. For example, implementing dialog boxes is a royal pain in the behind.

Xtreme was designed to allow for straightforward implementation of things like function plots. This goal has been archieved. The price for this simplicity is a severe loss in interactivity. (I'm tempted to say it's xtremely difficult to implement for instance a menu. Pun intened :-)

Another important design decision was to make Xtreme handle redraws. This implies that Xtreme must remember everything that has been written to the stream. Xtreme must store every circle, line, text or pixel. This implies that while a decent performance for vector graphics is easily maintained, excessive pixel graphics will seriously hurt performance. The big advantage, however, is that the program flow is completely transparent, as it is for files.

This locks neatly with the Unix philosophy, "everything is a file".


Last modified: Thu Aug 24 22:44:00 CEST 2000
Patrick Schemitz