Whether using a retained mode or an immediate mode graphics API, the programmer must specify the geometry that the API eventually draws onto a pixel buffer.  A pixel buffer is a two-dimensional array of pixels.  Those pixels are most naturally referenced by integer indices.

'''How do you represent geometry in a graphics API?  Do you use DiscreteCartesianGeometryPrimitives or ContinuousCartesianGeometryPrimitives?'''

One or more of these applies:
	* The renderer will run on machines with no graphics hardware accelerator.  Graphics are drawn by direct access to the pixel buffer by the CPU.  
	* The machine has quite slow processors (e.g. PDAs, mobile phones, embedded systems, etc.) with no FPU, so integer calculations are much faster than floating point calculations.  Therefore avoiding floating point calculations will reduce the amount of processing time used to render graphics.
	* The API will make it easy to apply affine transformations to the drawn geometry. E.g. rotating/scaling/shearing the geometry primitives. The API might use a SceneGraph or SingleTransform model to specify transformations.
	* The API may antialias the geometry that it renders, thereby simulating drawing between the actual pixels.

Simple frame-buffer graphics hardware is often used in PDAs, mobile phones, and embedded systems.  Such machines usually have quite slow processors so processing power is a scarce resource.  They also usually have no FPU so integer calculations are much faster than floating point calculations.  Avoiding floating point calculations will therefore reduce the amount of processing time used to render graphics.

However, programmers using the API demand fairly sophisticated facilities, including affine transformations and anti-aliasing.

Therefore:

'''Represent geometry using fixed-point values, which can be stored and manipulated using integer primitives.'''

With FixedPointCartesianGeometryPrimitives, it is possible to use sub-pixel positioning, which takes advantage of antialiasing and the display manager's SingleTransform.  Therefore, DiscreteCartesianGeometryPrimitives are not only really useful in a StructuredGraphics framework, but also work well in a SceneGraph.

Most languages do not natively support fixed point values, so maths with fixed point values (also known as FixedPrecisionInteger''''''s) is more verbose and harder to read than with the native numerical types.

----
This pattern is found in places in the JavaAdvancedImaging API, but it isn't pretty; ideally, there would be a Fixed type which implemented all the basic maths, but instead, it is done with plain integers, so code has to do all the twiddling itself. Worse, the scale isn't statically fixed, but determined by passing around scale factors, so each value is actually two integers - have fun trying to return a fixed-point value from a function ...

----
The core XwindowProtocol uses DiscreteCartesianGeometryPrimitives with 16-bit x and y values.  This was found lacking for many of the reasons above plus the limitations of 16-bit coordinate resolution. The Render extension was introduced to grant anti-aliasing via client-side glyph generation, image composition, sub-pixel rendering, and affine transforms.  Render uses FixedPointCartesianGeometryPrimitives, using a 24/8 integer/fract allocation.

----
Also see: GraphicsPatterns

CategoryPattern