David German - Engineering 26 Portfolio

Lab 2: 2D Graphics Primitives

In this lab exercise, I developed C libraries that constitute a simple 2D graphics system. This system abstracts from pixel space to mathematical space, enabling the user to define primitive objects as though they inhabit the real plane. Library functions rasterize those objects and output the resulting image files.

Procedure

My graphics system implements Prof. Maxwell's Graphics Environment Specification. It defines Image structures, which store rasterized graphics composed of Pixel structures. It also defines a structure to characterize Color, and structures for geometric definition of a Point, a Line, a Circle, and an Ellipse. It supplies routines to rasterize mathematical objects using Bresenham's algorithm, which achieves high performance by relying upon integer arithmetic. A few floating-point operations are required to draw an Ellipse, but their complexity does not grow with its size.

Results

I used the benchmark program Prof. Maxwell supplied to test the speed of my line-drawing routine. On coriander.cs.swarthmore.edu, which has dual AMD Opteron 248 processors running at 2.2 GHz, my implementation drew between 600,000 and 700,000 lines per second, with about 103 average pixels per line.

lots of lines
Image 1. Output of Prof. Maxwell's line-drawing benchmark.

My line drawing implementation yields mathematically correct rectangles when they are drawn counterclockwise.

A correct square
Image 2. A mathematically correct square.

Prof. Maxwell also supplied a test program to exercise all the primitives supported by the system.

crossed-out W
Image 3. Prof. Maxwell's test image, as rendered by my system. I am not responsible for the image's symbolic content.

I developed the following image using my system as an exercise in 3D line art. Aside from showcasing my mastery of perspective, it expresses my deepest reflections on the human condition.

choo-choo train!
Image 4. A choo-choo train!

Conclusions and Future Work

My graphics system suffers from aliasing. Antialiasing at the object level could be incorporated transparently into the existing Draw routines by drawing a supersampled version in white on a parallel, black image, performing an averaging downsample, and alpha blending into the existing image according to the output averages. Since future assignments will build upon this lab, and aliasing will only be more obvious in more complicated images, I am likely to add this feature soon.

All tests suggest that my lines are correct. Therefore, I believe that the one-pixel errors visible in Prof. Maxwell's test image are caused by mathematical incorrectness in my circles and ellipses. I am drawing the conic sections from the third quadrant, but they are not corner-coordinatized. This is a likely cause, and should be fixed.

From a software engineering perspective, I think my code is reasonably sturdy and adequately commented. I do wish better encapsulation were possible in C, to force the use of the accessors and mutators, but such safeguards would come at a performance price.

I did not expand upon the required API, but I did deviate from it on one minor issue. It suggests that a Point simply be represented as an array of floating-point numbers, which is reasonable. Early versions, also reasonably, specified that Point mutators and accessors would be passed a Point directly, but later versions call for a pointer to a Point. Since, as an array, a Point is itself a pointer, the later specification appeared to be not only an unnecessary hassle but also an unnecessary performance hit. My system therefore complies with the earlier version. Code anticipating the later interface will warn, but compile and run normally.

Appendices

As usual, my code is available with AES256 encryption. The passphrase is only available to Dr. Maxwell.