1 Performance
Abstract
Usage
Design
Results
Extended Features
Future Direction
Appendix
Acknowledgements
References

Table of Contents:

1.1 Benchmarking

In order to measure the frames per second (fps), I used the following benchmark implementation [12]: 

	#include <sys/types.h>
	#include <sys/timeb.h>
	static const unsigned int DELAY = 1;
	...
	// Performance Measurements for fps:
	// Timer callback function that measures the amount of time elasped between
	// scene renders:
	double time() {
    		struct _timeb t;

		// get the current local system time:
    		_ftime(&t);

    		return ((double)t.time) + 0.001*((double)t.millitm);
	}

	void timing(int value) {
    		glutTimerFunc(DELAY, timing, 0);

    		static double last = time();
    		static unsigned long count = 0;
    		if(++count % 100 == 0) {
        		double now = time();

			// measure the time elapsed
        		printf("%f fps\n", 100.0 / (now - last));
        		last = now;
    		}
	}

	void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) {
		...
		glutTimerFunc(DELAY, timing, 0);// Performance measurement:
		...
	}
This implementation essentially notes the system time, renders 100 frames, and then notes the system time again. The fps is then calculated as (100/elasped_time). I took measurements in 100 frame intervals to allow for more accurate measurements. I ran the benchmarks on my system which contained the following specs:
  • Pentium 4 Processor at 1.8GHz
  • 512 MB DDR SDRAM at 266MHz
  • 64MB GeForce4 MX Graphics Card
Rendering at a window size of 300 pixels by 300 pixels, I found that the measurements obtained were around 37 fps.

1.2 Performance Tuning

Generally, there are three types of limitations that can hurt the performance of the graphics application[10]:

CPU limited General term for performance limited by the speed of the CPU.
Geometry limited Term for performance limited by how fast the computer or graphics hardware can perform vertex computations.
Fill limited The render rate is limited by how fast your graphics hardware can fill pixels.
In order to determine the bottleneck in my application, there are some tests that can be performed. The easiest test was to first check whether the application was fill limited. This can be done by simply enlarging the window size and using the benchmark program to measure the speed at which it takes to render the spider. If the speed decreases (i.e., the fps decreases), then I know my application is fill limited. Consequently, I found that my application was indeed fill limited. That is, when I measured the performance at a window size of 300 pixels by 300 pixels, the results I obtained was approximately 37 fps. However, rendering at a window size of 1152 pixels by 815 pixels resulted in a slow down in performance. That is, the render rate went down to approximately 25 fps.