\input{chapters/Background/CoordinateSystems}
\section{Precision Specified by Document Standards}
-\input{chapters/Background/Standards/Precision}
+\input{chapters/Background/Standards}
\section{Rational Number Representations}
\input{chapters/Background/Rationals}
-\section{Floating Point Operations on the CPU and GPU}
+
+\section{Floating Point Operations on the CPU and GPU}\label{FloatingPointOnTheGPU}
\input{chapters/Background/FloatingPointOnTheGPU}
+
+
The effect of this transformation is that, measured relative to the view rectangle, the distance of primitives with coordinates $(x, y)$ to the point $(x_0, y_0)$ will decrease by a factor of $s$. For $s < 1$ the operation is ``zooming out'' and for $s > 1$, ``zooming in''.
+As we will see in Chapter \ref{Results and Discussion}, the application of the transformations discussed in this section can cause issues with the rendering of vector graphics even when the primitives are specified with coordinates compliant with the SVG standard.
+
%TODO List
% Mention that these transformations affect precision more than eg: drawing a line
A positive real number $z$ may be written as the sum of smaller integers ``digits'' $d_i$ multiplied by powers of a base $\beta$.
\begin{align}
- z &= d_0 \beta^0 + d_1 \beta^1 + d_2 \beta^2 + \text{ ...} = \displaystyle\sum_{i=-\infty}^{\infty} d_i \beta^{i}\label{fixedpointZ}
+ z &= \text{... } + d_{-1} \beta^{-1} + d_0 \beta^0 + d_1 \beta^1 + \text{ ...} = \displaystyle\sum_{i=-\infty}^{\infty} d_i \beta^{i}\label{fixedpointZ}
\end{align}
Where each digit $d_i < \beta$. A set of $\beta$ unique symbols are used to represent values of $d_i$.
A seperate sign '-' can be used to represent negative reals using equation \eqref{fixedpointZ}.
%\subsection{Rasterisation on the CPU and GPU}
-{\bf FIXME: I feel this section is important but I'm not quite sure where to place it; it could almost work as a paper by itself (in fact I sort of wrote one for it already...)}
-
Traditionally, vector images have been rasterized by the CPU before being sent to a specialised Graphics Processing Unit (GPU) for drawing\cite{computergraphics2}. Rasterisation of simple primitives such as lines and triangles have been supported directly by GPUs for some time through the OpenGL standard\cite{openglspec}. However complex shapes (including those based on B{\'e}zier curves such as font glyphs) must either be rasterised entirely by the CPU or decomposed into simpler primitives that the GPU itself can directly rasterise. There is a significant body of research devoted to improving the performance of rendering such primitives using the latter approach, mostly based around the OpenGL\cite{openglspec} API\cite{robart2009openvg, leymarie1992fast, frisken2000adaptively, green2007improved, loop2005resolution, loop2007rendering}. Recently Mark Kilgard of the NVIDIA Corporation described an extension to OpenGL for NVIDIA GPUs capable of drawing and shading vector paths\cite{kilgard2012gpu,kilgard300programming}. From this development it seems that rasterization of vector graphics may eventually become possible upon the GPU.
-It is not entirely clear how well supported the IEEE-754 standard for floating point computation is amongst GPUs\footnote{Informal technical articles are abundant on the internet --- Eg: Regarding the Dolphin Wii GPU Emulator: \url{https://dolphin-emu.org/blog} (accessed 2014-05-22)}. Although the OpenGL API does use IEEE-754 number representations, research by Hillesland and Lastra in 2004 suggested that many GPUs were not internally compliant with the standard\cite{hillesland2004paranoia}. In Section \ref{} we illustrate how the use of
-
+It is not entirely clear how well supported the IEEE-754 standard for floating point computation is amongst GPUs\footnote{Informal technical articles are abundant on the internet --- Eg: Regarding the Dolphin Wii GPU Emulator: \url{https://dolphin-emu.org/blog} (accessed 2014-05-22)}. Although the OpenGL API does use IEEE-754 number representations, research by Hillesland and Lastra in 2004 suggested that many GPUs were not internally compliant with the standard\cite{hillesland2004paranoia}.
+Figure \ref{gpufloats.pdf} shows the rendering of a circle through evaluation of $x^2 + y^2 < 1$ in an early version of the IPDF software (Chapter \ref{Process}) using an x86-64 CPU and various GPU models respectively. If we assume the x86-64 is IEEE-754 compliant performing the default rounding behaviour (to nearest) the GPUs are using different rounding behaviours which may not be IEEE-754 compliant.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\textwidth]{figures/gpufloats.pdf}\label{gpufloats.pdf}
+ \caption{CPU and GPU evaluation of $x^2 + y^2 < 1$ at $\approx 10^6$ magnification}
+\end{figure}
%Arbitrary precision arithmetic, is provided by many software libraries for CPU based calculations
+The use of floating point arithmetic in computer systems was pioneered by Knuth, Goldberg\cite{goldbern1967twentyseven}, Dekker, and others\cite{HFP}, but modern systems are largely compatable with the IEEE-754 standard pioneered by William Kahan in 1985 \cite{ieee754std1985} and revised (also with contributions from Kahan) in 2008\cite{ieee754std2008}. Recently, the ``Handbook of Floating Point Arithmetic''\cite{HFP} by Muller et al (2010) provides a detailed overview of IEEE-754 floating point arithmetic.
+
+
Whilst a Fixed Point representation keeps the ``point'' (the location considered to be $i = 0$ in \eqref{fixedpointZ}) at the same position in a string of bits, Floating point representations can be thought of as scientific notation; an ``exponent'' and fixed point value are encoded, with multiplication by the exponent moving the position of the point.
-The use of floating point arithmetic in computer systems was pioneered by Knuth, Goldberg{goldbern1967twentyseven}, Dekker, and others\cite{HFP}, but modern systems are largely compatable with the IEEE-754 standard pioneered by William Kahan in 1985 \cite{ieee754std1985} and revised (also with contributions from Kahan) in 2008\cite{ieee754std2008}.
A floating point number $x$ is commonly represented by a tuple of values $(s, e, m)$ in base $B$ as\cite{HFP, ieee2008-754}: $x = (-1)^{s} \times m \times B^{e}$
+It is of some historical significance that vector display devices were popular during the 70s and 80s, and papers oriented towards drawing on these devices can be found\cite{brassel1979analgorithm}. Whilst curves can be drawn at high resolution on vector displays, a major disadvantage was shading\cite{lane1983analgorithm}; by the early 90s the vast majority of computer displays were raster based\cite{computergraphics2}.
+
+
Hearn and Baker's textbook ``Computer Graphics''\cite{computergraphics2} gives a comprehensive overview of graphics from physical display technologies through fundamental drawing algorithms to popular graphics APIs. This section will examine algorithms for drawing two dimensional geometric primitives on raster displays as discussed in ``Computer Graphics'' and the relevant literature. This section is by no means a comprehensive survey of the literature but intends to provide some idea of the computations which are required to render a document.
-It is of some historical significance that vector display devices were popular during the 70s and 80s, and papers oriented towards drawing on these devices can be found\cite{brassel1979analgorithm}. Whilst curves can be drawn at high resolution on vector displays, a major disadvantage was shading\cite{lane1983analgorithm}; by the early 90s the vast majority of computer displays were raster based\cite{computergraphics2}.
+ We will restrict our focus to drawing the outlines of shapes, as the accuracy of shading a region will depend on the accuracy of the outline.
\input{chapters/Background/Standards/DOM}
\subsection{Precision Specified By Standards}
-{\bf TODO: Keep this subsection, appendicise rest of this section}
+%{\bf TODO: Keep this subsection, appendicise rest of this section}
\input{chapters/Background/Standards/Precision}
The World Wide Web Consortium (W3C) is an organisation devoted to the development of standards for structuring and rendering web pages based on industry needs. The DOM is used in and described by several W3C recommendations including XML\cite{xml2008-1.0}, HTML\cite{html2014-draft} and SVG\cite{svg2011-1.1}. XML is a general language which is intended for representing any tree-like structure using the DOM, whilst HTML and SVG are specifically intended for representing text documents and more general graphics respectively. These languages make use of Cascading Style Sheets (CSS)\cite{css2011-level2} for specifying the appearance of elements.
-%Version 5 of the Hypertext Markup Language (HTML5) is currently a candidate recommendation which aims to standardise the state of the art in technologies relating to web based documents. In HTML5 it is possible to achieve almost any level of control over both the structure and rendering of a document desirable. In particular, the language Javascript (based upon ECMAScript \cite{ecma-262}) can be used to dynamically alter a HTML5 document in response to user input or other events, including communication with HTTP servers.
+Version 5 of the Hypertext Markup Language (HTML5) is currently a candidate recommendation which aims to standardise the state of the art in technologies relating to web based documents. In HTML5 it is possible to achieve almost any level of control over both the structure and rendering of a document desirable. In particular, the language Javascript (based upon ECMAScript \cite{ecma-262}) can be used to dynamically alter a HTML5 document in response to user input or other events, including communication with HTTP servers.
The Scalable Vector Graphics (SVG) recommendation defines a language for representing vector images using the DOM. This is intended not only for stand alone images, but also for inclusion within HTML documents. In the SVG standard, each graphics primitive is an element in the DOM, whilst attributes of the element give information about how the primitive is to be drawn, such as path coordinates, line thickness, mitre styles and fill colours.
In the SVG representation, general shapes can be specified by locations of enclosed curves using B\'{e}zier splines (Section \ref{}) - the construction of these curves is very similar to PostScript (refer to Figure \ref{}). Again, text is created using vector fonts as described in Section \ref{}.
-
%Figure \ref{SVG} shows an example of an SVG image as rendered (left) and represented as text. The textual representation is syntactically a subset of XML and is similar to HTML.\footnote{The details of distinctions between these languages are beyond the scope of this report.} Here we have used \verb/<rect>/ elements to position rectangles and \verb/<path>/ elements to define a straight line and a filled region bounded by a cubic bezier spline; note that the points and type of curves are defined as a data attribute.
+Figure \ref{SVG} shows an example of an SVG image as rendered (left) and represented as text. The textual representation is syntactically a subset of XML and is similar to HTML.\footnote{The details of distinctions between these languages are beyond the scope of this report.} Here we have used \verb/<rect>/ elements to position rectangles and \verb/<path>/ elements to define a straight line and a filled region bounded by a cubic bezier spline; note that the points and type of curves are defined as a data attribute.
-\begin{comment}
+%\begin{comment}
\subsubsection{Javascript and the DOM}
Using Javascript, an element in the DOM can be selected by its type, class, name, or unique identifier, each of which may be specified as an attribute in the original DOM. Once an element is selected Javascript can be used to modify its attributes, add children below it in the DOM, or remove it from the DOM entirely.
\end{figure}
-\end{comment}
+%\end{comment}
Adobe's Portable Document Format (PDF) is currently used almost universally for sharing documents; the ability to export or print to PDF can be found in most graphical document editors and even some plain text editors\cite{cheng2002portable}.
-Hayes describes PDF as ``... essentially 'flattened' PostScript; it’s what’s left when you remove all the procedures and loops in a program, replacing them with sequences of simple drawing commands.''\cite{hayes2012pixels}. %Consultation of the PDF 1.7 standard shows that this statement does not a give a complete picture --- despite being based on the Adobe PostScript model of a document as a series of ``pages'' to be printed by executing sequential instructions, from version 1.5 the PDF standard began to borrow some ideas from the Document Object Model.
+Hayes describes PDF as ``... essentially 'flattened' PostScript; it’s what’s left when you remove all the procedures and loops in a program, replacing them with sequences of simple drawing commands.''\cite{hayes2012pixels}. Consultation of the PDF 1.7 standard shows that this statement does not a give a complete picture --- despite being based on the Adobe PostScript model of a document as a series of ``pages'' to be printed by executing sequential instructions, from version 1.5 the PDF standard began to borrow some ideas from the Document Object Model.
-%For example, interactive elements such as forms may be included as XHTML objects and styled using CSS. ``Actions'' are objects used to modify the data structure dynamically. In particular, it is possible to include Javascript Actions. Adobe defines the API for Javascript actions seperately to the PDF standard\cite{js_3d_pdf}. There is some evidence in the literature of attempts to exploit these features, with mixed success\cite{barnes2013embedding, hayes2012pixels}.
+For example, interactive elements such as forms may be included as XHTML objects and styled using CSS. ``Actions'' are objects used to modify the data structure dynamically. In particular, it is possible to include Javascript Actions. Adobe defines the API for Javascript actions seperately to the PDF standard\cite{js_3d_pdf}. There is some evidence in the literature of attempts to exploit these features, with mixed success\cite{barnes2013embedding, hayes2012pixels}.
-%Figure \ref{PS} shows a vector image and one possible way to express this image in PostScript.
+Figure \ref{PS} shows a vector image and one possible way to express this image in PostScript.
-%There are some limitations in PostScript's model. As mentioned in Section \ref{Compositing}, since PostScript predates Porter and Duff Compositing, there is no concept of transparency. In fact, using tools to convert between the SVG image in Figure \ref{SVG} and PostScript will simply rasterise the image and embed the rastered image in PostScript\footnote{For Figure \ref{SVG} converted using the Inkscape SVG editor: \url{http://szmoore.net/ipdf/figures/shape-svg-converted-to.ps}}
+There are some limitations in PostScript's model. As mentioned in Section \ref{Compositing}, since PostScript predates Porter and Duff Compositing, there is no concept of transparency. In fact, using tools to convert between the SVG image in Figure \ref{SVG} and PostScript will simply rasterise the image and embed the rastered image in PostScript\footnote{For Figure \ref{SVG} converted using the Inkscape SVG editor: \url{http://szmoore.net/ipdf/figures/shape-svg-converted-to.ps}}
-%Another limitation of PostScript is that the model of a document as a static page, convenient for printers which literally produce static pages, is unable to include interactive or dynamic elements. Dynamic PostScript attempted to fix this problem, but ``never caught on''\cite{hayes2012pixels}.
+Another limitation of PostScript is that the model of a document as a static page, convenient for printers which literally produce static pages, is unable to include interactive or dynamic elements. Dynamic PostScript attempted to fix this problem, but ``never caught on''\cite{hayes2012pixels}.
-\begin{comment}
+%\begin{comment}
\begin{figure}[H]
\begin{minipage}[t]{0.65\textwidth}
\begin{minted}{postscript}
Knuth's ``The {\TeX}book''\cite{knuth1984texbook} and ``The METAFONT book''\cite{knuth1983metafont} define two complementary programming languages for typesetting documents. Wheras PostScript may be considered an interpreted language, in that it can be produced in a human readable form which is also readable by an interpreter, {\TeX} is a compiled language; a program parses human readable {\TeX} to produce a machine readable format DVI (``DeVice Independent''). A DVI interpreter might be thought of as a virtual ``Display Processor'' for drawing vector graphics directly (as defined in the earlier editions of ``Computer Graphics''\cite{computergraphics2}).
DVI itself is not a widely used format for sharing documents. However, an system based upon {\TeX} called {\LaTeX} which includes libraries for advanced typesetting and programs that ultimately produce PDF output is particularly popular for producing technical reports and papers\footnote{The site \url{http://tex.stackexchange.com} (accessed 2014-05-22) is devoted to {\TeX} and {\LaTeX}} --- this report itself has been produced using the CTAN {\LaTeX} packages\footnote{The complete {\TeX} source code to produce this document can be found at \url{http://szmoore.net/ipdf/sam/}}.
-\end{comment}
+%\end{comment}
+In this section we will overview the statements made about the precision with which an object can be stored by various vector graphics and document standards.
+
\subsection{PostScript}
The PostScript reference describes a ``Real'' object for representing coordinates and values as follows: ``Real objects approximate mathematical real numbers within a much larger interval, but with limited precision; they are implemented as floating-point numbers''\cite{plrm}. There is no reference to the precision of mathematical operations, but the implementation limits \emph{suggest} a range of $\pm10^{38}$ ``approximate'' and the smallest values not rounded to zero are $\pm10^{-38}$ ``approximate''.
\subsection{SVG}
The SVG standard specifies a minimum precision equivelant to that of ``single precision floats'' (presumably referring to IEEE-754) with a range of \verb/-3.4e+38F/ to \verb/+3.4e+38F/, and states ``It is recommended that higher precision floating point storage and computation be performed on operations such as
-coordinate system transformations to provide the best possible precision and to prevent round-off errors.''\cite{svg2011-1.1} An SVG Viewer may refer to itself as ``High Quality'' if it uses a minimum of ``double precision'' floats.
+coordinate system transformations to provide the best possible precision and to prevent round-off errors.''\cite{svg2011-1.1} An SVG Viewer may refer to itself as ``High Quality'' if it uses a minimum of ``double precision'' floats for view transformations.
%\begin{comment}
\subsection{Javascript}
We include Javascript here due to its relation with the SVG, HTML5 and PDF standards.
There are many possible applications for documents in which precision is unlimited. Several areas of use include: visualisation of extremely large or infinite data sets; visualisation of high precision numerical computations; digital artwork; computer aided design; and maps.
-In collaboration with Gow\cite{} we have implemented a proof of concept document viewer compatable with a subset of the SVG standard, which has allowed us to explore the limitations of floating point arithmetic and possible approaches to achieving arbitrary precision document formats. Using the Rational representation of the GNU Multiple Precision (GMP) library\cite{granlund2004GMP} we are able to implement correct rendering of SVG test images seperated by arbitrary distances. We present measurements of rendering accuracy and performance for our implementation.
+In collaboration with Gow\cite{} we have implemented a proof of concept document viewer compatable with a subset of the SVG standard, which has allowed us to explore the limitations of floating point arithmetic and possible approaches to achieving arbitrary precision document formats. Using the Rational representation of the GNU Multiple Precision (GMP) library\cite{granlund2004GMP} we are able to implement correct rendering of SVG test images seperated by arbitrary distances. We present measurements of rendering accuracy and performance for our implementation. An alternative implementation based on a spatial approach to constructing the document is discussed by Gow\cite{}.
-\chapter{Methods and Design}
+\chapter{Methods and Design}\label{Process}
\section{Structure of Software}
-A custom vector graphics viewer called IPDF\footnote{The original name ``Infinite Precision Document Format'' stuck, although the word ``Infinite'' is highly misleading} was implemented for this project in collaboration with David Gow\cite{}. We will give a brief overview of the features and limitations of this software.
+A custom vector graphics viewer called IPDF\footnote{The original name ``Infinite Precision Document Format'' stuck, although the use of the word ``infinite'' is highly misleading} was implemented for this project in collaboration with David Gow\cite{}. We will give a brief overview of the features and limitations of this software.
\subsection{Document Structure}
\subsection{Rendering Process}
-As discussed in Section \ref{} it is not clear to what extend GPUs comply with the IEEE-754 standard, and arbitrary precision arithmetic is most easily implemented on the CPU; for this reason a CPU renderer and GPU renderer were implemented.
+As discussed in Section \ref{FloatingPointOnTheGPU
+} it is not clear to what extend GPUs comply with the IEEE-754 standard, and arbitrary precision arithmetic is most easily implemented on the CPU; for this reason a CPU renderer and GPU renderer were implemented.
All Objects are represented by their bounding rectangles; in the case of B\'{e}zier curves the control points are stored relative to the bounding rectangle. The rendering process involves converting the bounding rectangle coordinates from Document to Screen space as discussed in Section \ref{}. For both GPU and CPU rendering a B\'{e}zier in screen space is decomposed into straight lines; the CPU renders these lines using Bresenham's algorithm.
-\chapter{Results and Discussion}
+\chapter{Results and Discussion}\label{Results and Discussion}
\section{Qualitative Rendering Accuracy}
Our ultimate goal is to be able to insert detail at an arbitrary point in the document. Therefore, we are interested in how the same test SVG would appear when scaled to the view coordinates, as the view coordinates are varied.
-\subsection{Applying the view transformation directly}
+\subsection{Applying the view transformation directly}\label{direct_transform}
Figure \ref{qualitative-rendering-fox} shows the rendering of a vector image\footnote{Unfortunately, since a rendered vector image is a raster image and this figure must be scaled to fit the PDF, the figure as seen here is not a pixel perfect representation of the actual rendering. Most notably, antialiasing effects will be apparent}. Transformation \eqref{view-transformation} is applied to object coordinates with default IEEE-754 rounding behaviour (to nearest). The loss of precision in the second figure is obvious. This is because division by $10^{-6}$ increases the rounding error in $x - v_x$, by $10^{6}$, so the total error is of the order $10^6$ ulp which is of the order $0.25$
-{\bf TODO: Calculate that properly, shouldn't be hard}
-
-
\begin{figure}[H]
\centering
\caption{The vector image from Figure \ref{vector-vs-raster} under two different scales}\label{qualitative-rendering-fox}
\end{figure}
-\subsection{Applying cumulative transformations to all B\'{e}ziers}
+\subsection{Applying cumulative transformations to all B\'{e}ziers}\label{cumulative_transform}
Rather than applying \eqref{view-transformation} to object coordinates specified relative to the document, we can store the bounds of objects relative to the view and modify these bounds according to transformations \eqref{} and \eqref{} as the view is changed. This is convenient for an interactive document, as detail is typically added by inserting objects into the document within the view rectangle. As a result this approach makes the rendering of detail added to the document independent of the view coordinates --- until the view is moved.
\caption{The effect of applying cumulative transformations to all B\'{e}ziers}\label{qualitative-rendering-fox-cumulative}
\end{figure}
-\subsection{Applying cumulative transformations to Paths}
+\subsection{Applying cumulative transformations to Paths}\label{path_transform}
In Figure \ref{qualitative-rendering-fox}, transformations are applied to the bounds of each B\'{e}zier. Figure \ref{qualitative-rendering-fox-cumulative-relative} a) shows the effect of introducing an intermediate coordinate system expressing B\'{e}zier coordinates relative to the path which contains them. In this case, the rendering of a single path is accurate, but the overall positions of the paths drift as the view is moved.
-We can correct this drift whilst maintaining performance by using an arbitrary or high precision number representation to express the coordinates of the paths - but maintaining the floating point coordinates for B\'{e}zier curves relative to their path. As we will discuss in Section \ref{}, this offers an acceptable trade off between rendering accuracy and performance.
+We can correct this drift whilst maintaining performance by using an arbitrary or high precision number representation to express the coordinates of the paths - but maintaining the floating point coordinates for B\'{e}zier curves relative to their path. This is shown in Figure \ref{qualitative-rendering-fox-cumulative-relative} b).
\begin{figure}[H]
\centering
\includegraphics[width=800px]{figures/fox-vector_cumulative_relative_to_path_GMPrat.png}
\caption{Effect of cumulative transformations applied to Paths\\a) Path bounds represented using floats b) Path bounds represented using Rationals}\label{qualitative-rendering-fox-cumulative-relative}
\end{figure}
+
+Videos showing the effects discussed in Section \ref{direct_transform}, \ref{cumulative_transform} and \ref{path_transform} can be found at:
+
+ \url{http://szmoore.net/ipdf/sam/presentation}.
\section{Quantitative Measurements of Rendering Accuracy}
\end{figure}
-\subsection{Names of programs in figures}
-\begin{itemize}
- \item single - Single precision IEEE-754 with \eqref{view-transformation} applied directly
- \item double - Double precision IEEE-754 with \eqref{view-transformation} applied directly
- \item cumul-single - Single precision IEEE-754 with cumulative transforms to B\'{e}ziers
- \item cumul-double - Double precision IEEE-754 with cumulative transforms to B\'{e}ziers
- \item path-single - Single precision IEEE-754 with cumulative transforms to Paths
- \item path-double - Single precision IEEE-754 with cumulative transforms to Paths
- \item path-rat - GNU MP Rationals with cumulative transforms to Paths
-\end{itemize}
-
\subsection{Precision for Fixed View}
By counting the number of distinctly representable lines within a particular view, we can show the degradation of precision quantitatively. The test grid is added to each view rectangle.
-Figure \ref{loss_of_precision_grid_0.5.pdf} shows how precision degrades with $(v_x, v_y) = (0.5,0.5)$.
-A constant line at $1401$ grid locations indicates no loss of precision.
+Figure \ref{loss_of_precision_grid_0.5.pdf} shows how precision degrades with $(V_x, V_y) = (0.5,0.5)$ for different precision settings using MPFR floating point values to represent the view coordinates. A constant line at $1401$ grid locations indicates no loss of precision. From this figure it is clear that
\begin{figure}[H]
By considering Figure \ref{loss_of_precision_grid_0.5.pdf} and \ref{cumulative_error_grid.pdf}, \verb/path-rat/ is the winner.
-\section{Performance Measurements whilst Rendering}
+\section{Performance Measurements}
As discussed above, we succeeded in preserving rendering accuracy as defined above for an arbitrary view.
-However this comes at a performance cost, as the size of the Rational number representation must grow accordingly. Figures \ref{memory.pdf} and \ref{time.pdf} were obtained by repeatedly clearing the document, scaling, and adding a fixed number of B\'{e}zier curves.
+However this comes at a performance cost, as the size of the Rational number representation must grow accordingly. Figures \ref{memory.pdf} and \ref{time.pdf} were obtained by repeatedly clearing the document, scaling, and adding a fixed number of B\'{e}zier curves. The \texttt{mpfr-1024} number representation performs much better in terms of memory usage and performance; however as discussed in Section \ref{}, due to the fixed precision it cannot represent detail seperated by a truly arbitrary distance.
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\textwidth]{figures/memory.pdf}
+ \includegraphics[width=0.7\textwidth]{figures/memory.pdf}
\label{memory.pdf}
- \caption{Memory used per Rational whilst zooming in}
+ \caption{Memory used per Path coordinate whilst zooming in}
\end{figure}
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\textwidth]{figures/time.pdf}
+ \includegraphics[width=0.7\textwidth]{figures/time.pdf}
\label{time.pdf}
\caption{Time taken to scale about the fixed point}
\end{figure}
git.ucc.asn.au / ipdf / sam.git / commitdiff
UCC git Repository :: git.ucc.asn.au