THE FINAL COUNTDOWN
[ipdf/sam.git] / chapters / Conclusion.tex
1 \chapter{Conclusion}\label{Conclusion}
2
3 \section{Work Achieved}
4
5 In this project we have explored and identified the issues limiting precision in vector graphics formats.
6 A primitive such as a B\'{e}zier curve can be decomposed into straight lines and rendered on a display to sub-pixel accuracy using IEEE-754 floating point representations, but creating a document using coordinates specified with a floating point representation limits the locations at which detail can be included. 
7
8 By implementing a proof of concept SVG viewer, we have shown how the approach to applying coordinate transformations affects the accuracy of rendering. Using arbitrary precision GMP rationals to form the coordinates of SVG path elements, expressing B\'{e}zier bounds relative to the paths, we have demonstrated the ability to reduce rendering error and include detail accross an extremely large scale. Performance tests show that this implementation is comparable to a straight forward implementation for a very large number of B\'{e}zier's in the document.
9
10
11
12 \section{Limitations and Future Work}
13
14 As seen in Figure \ref{cumulative_error_grid.pdf} the error for an implementation based on GMP rationals and path coordinates still increases very slowly with scaling, as the final transformation requires conversion to IEEE-754 floats. Our tests have typically been limited to ranges of values represented by IEEE-754 double precision floats, due to time constraints. Future work should address this gradual accumulation of error, particularly outside the range of IEEE-754 values.
15
16 Another limitation of our implementation is that only straight lines with starting and ending coordinates in the display will be rendered accurately using Bresenham's algorithm. When ``zooming in'' to a point within a path, the size of lines increases beyond that of the display, and a rounding error is present. This may be a minor problem unless the view is scaled to an intersection point of lines, in which case the intersection may move. Future work should explore this issue.
17
18 The MPFR arbitrary precision floating point implementation allows for individually altering the precision of a number. As an alternative to GMP rationals, which automatically increase in size as needed, algorithms for dynamically increasing the precision of MPFR floats could be explored.
19
20 Gow has been exploring a spatial approach to constructing a document, which allows detail to be scaled indefinitely whilst using only IEEE-754 single precision floating point representations \cite{thesisGow}. This implementation could be compared to ours in more detail. It may be possible to apply the Quad tree approach to perform sub division of the path based coordinate systems to overcome some of the limitations of both approaches.
21
22 Arbitrary precision arithmetic is well understood, but from our review of the literature we have found little evidence of it's application to vector graphics. The well known graphics standards mention precision in passing, if at all. Ideally this work would motivate future document standards which can include detail at potentially arbitrary precision.
23
24 \begin{comment}
25 \begin{itemize}
26         \item What we have done?
27         \begin{itemize}
28                 \item Implemented a basic SVG viewer
29                 \item Demonstrated how precision affects rendering vector graphics
30                 \item Showed how the choice of transformations to apply affects rendering
31                 \item Using GMP rationals, demonstrated the ability to render SVGs scaled to an arbitrary position in a document
32         \end{itemize}
33         \item Possible future work
34         \begin{itemize}
35                 \item Implement more of the SVG standard (eg: Shading)
36                 \item Trial alternative number representations, eg: MPFR with algorithm to set precision
37                 \item Allow for saving and loading SVGs with arbitrary precision
38                 \item Deal with zooming very far in to intersection of lines (requires subdividing paths)
39                 \item Compare with David's Quadtree
40         \end{itemize}
41 \end{itemize}
42 \end{comment}

UCC git Repository :: git.ucc.asn.au