Restructure chapters, delete a bunch of words, add more words, do some things, panic...

[ipdf/sam.git] / chapters / Process / Transformations.tex

diff --git a/chapters/Process/Transformations.tex b/chapters/Process/Transformations.tex
new file mode 100644 (file)
index 0000000..9f586ab
--- /dev/null
+++ b/chapters/Process/Transformations.tex
@@ -0,0 +1,38 @@
+Equation \eqref{view-transformation} involves a division operation; in general, the result cannot be represented exactly in either a fixed or floating point format. However, if the coordinates involved are expressed as rational numbers, the result will always be exact.
+
+
+       
+
+\begin{enumerate}
+       \item Store static object bounds, transform to view before rendering
+       \begin{itemize}
+               \item Straight foward approach
+               \item Causes the most obvious rounding errors; impossible to render objects accurately below epsilon
+               \item The transformation can be performed by the GPU or CPU; the GPU is restricted to floats
+               \item CPU can perform transformation to arbitrary precision, but this requires all object bounds to be expressed with arbitrary precision
+       \end{itemize}
+       \item Modify all object bounds, no transformation required before rendering
+       \begin{itemize}
+               \item The rounding error on floats does not accumulate as quickly
+               \item Instead of one division by a very small number there are repeated divisions by larger numbers
+               \item However, if the document is scaled so object bounds $\to 0$ then the object will not be recoverable
+               \item For arbitrary precision we still need to apply all bounds transformations on the GPU
+       \end{itemize}
+       \item Keep object bounds static to some intermediate object and transform the bounds of that object
+       \begin{itemize}
+               \item We have used SVG \verb/<path>/ to construct the intermediate objects; all beziers are relative to their parent path.
+               \item One could instead use the entire SVG bounds; however
+                       for an SVG with a high level of detail this would have problems \rephrase{elaborate}.
+               \item We only need to apply some bounds transformations on the CPU
+               \item However as the document grows we still need to apply transformations to all paths, even those that are not visible 
+       \end{itemize}
+       \item Quad tree
+       \begin{itemize}
+               \item Divide space up into a quad tree
+               \item Refer to David's stuff
+               \item The advantage over Path based transformations is that the bounds of objects which are not visible do not need to be recalculated
+       \end{itemize}
+       
+\end{enumerate}
+
+