+\section{Scalable Vector Graphics (SVG) 1.1 (Second Edition) \cite{svg2011-1.1}}
+
+Scalable Vector Graphics (SVG) is a XML language for describing two dimensional graphics. This document is \url{http://www.w3.org/TR/2011/REC-SVG11-20110816/}, the latest version of the standard at the time of writing.
+
+\subsubsection{Three types of object}
+\begin{enumerate}
+ \item Vector graphics shapes (paths)
+ \item Images (embedded bitmaps)
+ \item Text
+\end{enumerate}
+
+\subsubsection{Rendering Model and Precision}
+
+SVG uses the ``painter's model''. Paint is applied to regions of the page in an order, covering the paint below it according to rules for alpha blending.
+
+``Implementations of SVG are expected to behave as though they implement a rendering (or imaging) model cor-
+responding to the one described in this chapter. A real implementation is not required to implement the model in
+this way, but the result on any device supported by the implementation shall match that described by this model.''
+
+SVG uses {\bf single precision floats}. Unlike PDF and PostScript, the standard specifies this as a {\bf minimum} range from \verb/-3.4e+38F/ to \verb/+3.4e+38F/
+
+``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.''
+
+There is also a ``High Quality SVG Viewers'' requirement to use at least {\bf double} precision floats.
+
+\section{OpenVG Specification 1.1 \cite{rice2008openvg}}
+``OpenVG is an application programming interface (API) for hardware-accelerated two-
+dimensional vector and raster graphics developed under the auspices of the Khronos
+Group \url{www.khronos.org}.''
+
+Specifically, provides the same drawing functionality required by a high-performance SVG document viewer (SVG Tiny 1.2)
+TODO: Look at that $\neq$ SVG 1.1
+
+It is designed to be similar to OpenGL.
+
+\subsubsection{Precision}
+``All floating-point values are specified in standard IEEE 754 format. However,
+implementations may clamp extremely large or small values to a restricted
+range, and internal processing may be performed with lesser precision. At least
+16 bits of mantissa, 6 bits of exponent, and a sign bit must be present, allowing
+values from $\pm 2^{-30}$ to $\pm2^{31}$ to be represented with a fractional precision of at least 1
+in $2^{16}$.''
+
+IEEE but with a non standard number of bits.
+
+Presumably the decreased precision is for increased efficiency the standard states that example applications are for ebooks.
+
+
+\section{Document Object Model --- pugixml 1.4 manual \cite{pugixmlDOM}}
+
+Pugixml is a C++ library for parsing XML documents\cite{kapoulkine2014pugixml}. XML is based on the Document Object Model (DOM); this is explained pretty well by the pugixml manual.
+
+The document is the root node of the tree. Each child node has a type. These may
+\begin{itemize}
+ \item Have attributes
+ \item Have child nodes of their own
+ \item Contain data
+\end{itemize}
+
+In the case of HTML/SVG an XML parser within the browser/viewer creates the DOM tree from the XML (plain text) and then interprets that tree to produce the objects that will be rendered.
+
+Example of XML $\to$ DOM tree given at\cite{pugixmlDOM}.
+Example of XML parsing using pugixml is in \shell{code/src/tests/xml.cpp}
+
+
+\begin{figure}[H]
+ \centering
+\begin{lstlisting}[language=XML,basicstyle=\ttfamily]
+<?xml version="1.0"?>
+<mesh name="mesh_root">
+ <!-- here is a mesh node -->
+ some text
+ <![CDATA[someothertext]]>
+ some more text
+ <node attr1="value1" attr2="value2" />
+ <node attr1="value2">
+ <innernode/>
+ </node>
+</mesh>
+<?include somedata?>
+\end{lstlisting}
+
+ \includegraphics[width=0.6\textwidth]{references/pugixmlDOM-dom_tree.png}
+ \caption{Tree representation of the above listing \cite{pugixmlDOM}}
+\end{figure}
+
+\section{An Algorithm For Shading of Regions on Vector Display Devices \cite{brassel1979analgorithm}}
+
+All modern display devices are raster based and therefore this paper is mainly of historical interest. It provides some references for shading on a raster display.
+
+The algorithm described will shade an arbitrary simply-connected polygon using one or two sets of parallel lines.
+
+The ``traditional'' method is:
+\begin{enumerate}
+ \item Start with a $N$ vertex polygon, rotate coords by the shading angle
+ \item Determine a bounding rectangle
+ \item For $M$ equally spaced parallel lines, compute the intersections with the boundaries of the polygon
+ \item Rotate coordinates back
+ \item Render the $M$ lines
+\end{enumerate}
+
+This is pretty much exactly how an artist would shade a pencil drawing. It is $O(M\times N)$.
+
+The algorithm in this paper does:
+\begin{enumerate}
+ \item Rotate polygon coords by shading angle
+ \item Subdivide the polygon into trapezoids (special case triangle)
+ \item Shade the trapezoids independently
+ \item Rotate it all back
+\end{enumerate}
+It is more complicated than it seems. The subdivision requires a sort to be performed on the vertices of the polygon based on their rotated $x$ and $y$ coordinates.
+
+\section{An Algorithm For Filling Regions on Graphics Display Devices \cite{lane1983analgorithm}}
+
+This gives an algorithm for for polygons (which may have ``holes'').
+It requires the ability to ``subtract'' fill from a region; this is (as far as I can tell) difficult for vector graphics devices but simple on raster graphics devices, so the paper claims it is oriented to the raster graphics devices.
+
+If the polygon is defined by $(x_i, y_i)$ then this algorithm iterates from $i = 2$ and alternates between filling and erasing the triangles $[(x_i, y_i), (x_{i+1}, y_{i+1}), (x_1, y_1)]$. It requires no sorting of the points.
+
+The paper provides a proof that the algorithm is correct and is ``optimal in the number of pixel updates required for convex polygons''.
+In the conclusion it is noted that trapezoids could be used from a fixed line and edge of the polygon, but this is not pixel optimal.
+
+This paper doesn't have a very high citation count but it is cited by the NVIDIA article \cite{kilgard2012gpu}.
+Apparently someone else adapted this algorithm for use with the stencil buffer.
+
+\section{GPU-accelerated path rendering \cite{kilgard2012gpu, kilgard300programming}}
+
+Vector graphics on the GPU; an NVIDIA extension. \cite{kilgard300programming} is the API.
+
+Motivations:
+\begin{itemize}
+ \item The focus has been on 3D acceleration in GPUs; most path rendering is done by the CPU.
+ \item Touch devices allow the screen to be transformed rapidly; CPU rastering of the path becomes inefficient
+ \begin{itemize}
+ \item The source of the ugly pixelated effects on a smartphone when scaling?
+ \end{itemize}
+ \item Especially when combined with increased resolution of these devices
+ \item Standards such as HTML5, SVG, etc, expose path rendering
+ \item Javascript is getting fast enough that we can't blame it anymore (the path rendering is the bottleneck not the JS)
+ \item GPU is more power efficient than the CPU
+\end{itemize}
+
+Results show the extension is faster than almost every renderer it was compared with for almost every test image.
+
+Comparisons to other attempts:
+\begin{itemize}
+ \item Cairo and Glitz \cite{nilsson2004glitz} (abandoned)
+\ \item Direct2D from Microsoft uses CPU to tesselate trapezoids and then renders these on the GPU
+ \item Skia in Android/Chrome uses CPU but now has Ganesh which is also hybrid CPU/GPU
+ \item Khronos Group created OpenVG\cite{rice2008openvg} with several companies creating hardware units to implement the standard. Performance is not as good as ``what we report''
+\end{itemize}
+
+