Draw a line by clicking and
dragging on the pixel grid shown with the left mouse button. An ideal line is
displayed until the left button is released. Upon release a discrete approximation
of the line is drawn on the display grid using the lineDDA() method described
in the previous slide. An ideal line is then overlaid for comparison.
You should not see any difference in the lines generated by this method and the lineImproved( ) method mentioned previously.
The main difference should only be speed, (the methodalso draw in a different color). When optimizing, it is important to verify at each step that the algorithm remains intact.
A parting note: Many modern optimizing compilers will automatically find the sorts of optimizations that we applied here (inlining function calls within loops and converting functions to incremental calculation). In order to check if your compiler is so clever, you'll need to do one of two things: look at the code it generated or write a test fragment to time your optimized code.
This raises the question: Is it better to retain readable code, and depend a
compiler to do the optimization implicitly, or code the optimization explicitly
with some loss in readability? The answer is not clear cut. In general, you
should make your code as readable as possible. Comments can go a long way in
addressing this in optimized code. On the other hand, you should also seldom
trade-off portability for elegance. Thus, if your application depends on a fast
algorithm, you are better off coding directly rather than requiring on a compiler
to do your work, because in all likelyhood, compiler versions and platforms
will change more frequently than your code!