Graphics hierarchy

[Alastair David Reid]

> I propose changing "Drawing" to "Rendering", because this a more
> common term in computer graphics. But I'm no native speaker, so I'd
> like to hear some comments on this.

Sounds good - in those cases where we really can separate rendering from UI.

> Another problem is that in "real world" APIs the above
> subcategeories are often mixed up a bit. Have a look at the
> following APIs resp. Haskell libraries:

>    Clean ObjectIO Direct3D FRAN FranTk Fudgets Functional Metapost
> GIFWriter GLUT GTK+ Haven HGL Inventor MOTIF OpenGL Pan TclHaskell
> Win32 X toolkit intrinsics Xaw Xlib Xmu

> Where should we put them in the new hierarchy? Do we need more/other
> subcategories?

A bunch of these are tied to particular systems and provide both
rendering and UI functionality.  It seems that splitting these would
be rather artificial - they look separate but neither is useful
without the other and neither can be combined with other systems.

Even the HGL -which would split reasonably well- would look a bit
funny since you can only use HGL primitives to render onto HGL
windows.

The only way round this that I can see is to come up with a standard
API for interaction between the UI part and the rendering part so that
you can combine any UI with any renderer.  

It's not clear what this would look like.  For example, would device
contexts (aka graphics contexts) be explicit as in Win32 and X11 or
would they be implicit as in HGL?  What is clear though is that they
would not be the Win32 API, the X11 API, the Motif API, etc. since
they are all tied to one particular backend.

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/