At a minimum, this library must provide a vendor-independent high-performance vector and polygon display capability, similar to the display manager facility in mged. The minimum set of target "vendors" are:
Lee Butler has proposed a more extensive goal, to consider pixels as 3-D geometric objects. In this scenario, the framebuffer library libfb capability would be incorporated into this new library. There are several possibilities: pixels might be non-rotatable overlays with a given screen Z depth, or pixels might be full three dimensional objects, lying on a plane in space.
In order to make this capability most widely usable, both to ARL and to the wider community, we need a TCL/Tk binding for this new library, so that the new library is available as a new high performance TK widget. Given that there will be a Tk interface, is it necessary/desirable to have a lower level "raw" programming interface, or is it possible to make the Tk widget interface fast enough and general enough that it's the only interface we need to build?
The present mged display manager interface provides two styles of interface: immediate mode and display list mode.
For performance, it is necessary to be able to send arrays of vlist structures to the display library in bulk.
PHD wants to be able to apply texture maps to polygons as well, to provide visual cues. Also flashing.