July 2001
Visual API
Goals
- Strongly typed, to take advantage of compile-time checks
- Explicit; rendering should not be based on the current programmatic context
- Render free; no more refreshing or explicit drawing of elements
- Screen independence; screen resolution or size are explicit if required to render
- Simple; for quick acceptance
The Visual API was created to be:
OpenGL was great for its time, but has a couple of major drawbacks. The first is lack of type safety. Points and lines and the their rendering contexts are all the same type of 'object'. Debugging OpenGL code sucks. The extra dimension added to the object structure (0=vector, 1=point) does not help because the compiler can not check these values. You must add extra lines of code for run-time checks.
The same complication happens with transformation matrices. The distinction between object transformations and perspective transformations can not be made. Therefore it is possible for the same 'object' to act as an impostor and have more than one instance of itself on the screen. Some programmers still think this obfuscation is good for efficiency.
The second drawback is the fact that the GL primitives are render based. The programmer is responsible for refreshing the screen.
Still, in many graphics API's we see this same thing.
Vectors, Points and Contexts
This exposition is best started with some examples to provide a framework for the abstract thoughts discussed later. I will be rendering all my contexts with a grid and two 'basis' vectors. The tails of the basis vectors will be at the origin of the context. My points and vectors will be in colour.
 |
 |
 |
|
|
|
|
Context is needed everywhere, points and vectors have nothing measurable about them unless a context is involved. The above diagrams illustrate the roll of context in the definition of a point. Diagram P1 shows a point without context. We can not know anything about this point except that it exists. It is even not known if this point is two or three dimensional. P2 shows the same point in a context. Now we are able to describe the point's position with respect to the origin (Origin + 3*blue + 4*green), and say that the point is 2 dimensional. P3 illustrates the importance of context in describing a point, we have the same point again in another context. This time the position can be described as (Origin + 5*blue + 0*green). The two contexts do not have to be exclusive: one could be considered a ground context, the other a flying context.
|
 |
|
|
|
These next two diagrams show the relativity of context. C1 is just like P3, the point is (Origin + 5*blue + 0*green). C2 shows the same point and the same context: the point is (Origin + 5*blue + 0*green). You, as the reader, may have used the screen context to compare the two diagrams and determine that the latter has a skew. But technically you can not compare two contexts unless their origin and basis vectors of one are defined in terms of the other, like so:
C2.green = (C1.blue + C2+green)/sqrt(2)
C2.blue = C1.blue
C2.Origin= C1.Orgin
Context is needed for the interpretation and measurement of vectors and points. A context is always one point (the Origin) and one or more basis vectors (each corresponding to a dimension). All other points and vectors must be defined in terms of these. This definition of Euclidean space allows for the blending of many different dimensions with all the same primitives. The distinction between a 2D and 3D vector requires a context for comparison. Most other rendering systems do not allow such conversions, or make restrictive assumptions (z=0). One application of this dimensionally-free definition: it will allow a 2D definition of a glyph to be minimal and sufficient for 3D rendering.
A vector is a displacement in space. This displacement can only be measured, or communicated, if put in a context. Vectors come in two forms, independent and dependent. The former depend on a context for definition (3*blue + 4*green), and the latter are algebraic combinations of the first.
Points are simply defined as a point plus a vector. This forces us to have one special point, the Origin. Actually, the Origin is not really special, nor does it break the uniform definition of a Point. The Origin is still defined as itself plus the zero vector (Origin = Origin + sumOf(0 * basis vectors)).
Visual Elements, Primitives and Containers
Visual elements are either primitives or containers.
There is only one visual primitive, and it is the convex polygon. The great thing about the convex polygon is the fact that the points that define it do not have to be ordered. This frees the point ordering to suit other optimization needs.
Lines and points have not been chosen because they imply a fundamental screen resolution. The line assumes a single pixel width, this assumption must be made explicit to achieve resolution insensitive rendering.
In the future, other primitives may be added. Other geometric shapes, especially the circle, and three dimensional volumes, like the convex polyhedron or sphere.
Visual containers are sets of visual elements. They are used to construct more complex elements.
Visual Templates
Visual templates are a specialization of templates. Visual templates are containers that use a prototype (an example) to construct a family of visual objects. For example, the line is a template that takes 2 points and a context to render the appropriate polygon. The template system allows complex objects to be built from simple ones yet maintain a simple interface.
May 2000 Initial draft
May 2001, Rewrote completly based on different fundamental implementation, added graphics
July 23, 2001 Finished final draft