LitReviewDavid.tex

   1 \documentclass[a4paper,10pt]{article}
   2 \usepackage[utf8]{inputenc}
   3 \usepackage{hyperref}
   4 \usepackage{graphicx}
   5
   6 %opening
   7 \title{Literature Review}
   8 \author{David Gow}
   9
  10 \begin{document}
  11
  12 \maketitle
  13
  14 \section{Introduction}
  15
  16 Since mankind first climbed down from the trees, it is our ability to communicate that has made us unique.
  17 Once ideas could be passed from person to person, it made sense to have a permanent record of them; one which
  18 could be passed on from person to person without them ever meeting.
  19
  20 And thus the document was born.
  21
  22 Traditionally, documents have been static: just marks on paper, but with the advent of computers many more possibilities open up.
  23
  24 \section{Document Formats}
  25
  26 Most existing document formats --- such as the venerable PostScript and PDF --- are, however, designed to imitate
  27 existing paper documents, largely to allow for easy printing. In order to truly take advantage of the possibilities operating in the digital
  28 domain opens up to us, we must look to new formats.
  29
  30 Formats such as \texttt{HTML} allow for a greater scope of interactivity and for a more data-driven model, allowing
  31 the content of the document to be explored in ways that perhaps the author had not anticipated.\cite{hayes2012pixels}
  32 However, these data-driven formats typically do not support fixed layouts, and the display differs from renderer to
  33 renderer.
  34
  35 Existing document formats, due to being designed to model paper,
  36 have limited precision (8 decimal digits for PostScript\cite{plrm}, 5 decimal digits for PDF\cite{pdfref17}).
  37 This matches the limited resolution of printers and ink, but is limited when compared to what aught to be possible
  38 with ``zoom'' functionality, which is prevent from working beyond a limited scale factor, lest artefacts appear due
  39 to issues with numeric precision.
  40
  41 \section{Rendering}
  42
  43 Computer graphics comes in two forms: bit-mapped (or raster) graphics, which is defined by an array of pixel colours,
  44 and \emph{vector} graphics, defined by mathematical descriptions of objects. Bit-mapped graphics are well suited to photographs
  45 and are match how cameras, printers and monitors work. However, bitmap devices do not handle zooming beyond their
  46 ``native'' resolution --- the resolution where one document pixel maps to one display pixel ---, exhibiting an artefact
  47 called pixelation where the pixel structure becomes evident. Attempts to use interpolation to hide this effect are
  48 never entirely successful, and sharp edges, such as those found in text and diagrams, are particularly effected.
  49
  50 Vector graphics lack many of these problems: the representation is independent of the output resolution, and rather
  51 an abstract description of what it is being rendered, typically as a combination of simple geometric shapes like lines,
  52 arcs and ``B\'ezier curves''.
  53 As existing displays (and printers) are bit-mapped devices, vector documents must be \emph{rasterized} into a bitmap at
  54 a given resolution. This bitmap is then displayed or printed. The resulting bitmap is then an approximation of the vector image
  55 at that resolution.
  56
  57 This project will be based around vector graphics, as these properties make it more suited to experimenting with zoom
  58 quality.
  59
  60
  61 The rasterization process typically operates on an individual ``object'' or ``shape'' at a time: there are special algorithms
  62 for rendering lines\cite{bresenham1965algorithm}, triangles\cite{giesen2013triangle}, polygons\cite{pineda1988parallel} and B\'ezier
  63 Curves\cite{goldman_thefractal}. Typically, these are rasterized independently and composited in the bitmap domain using Porter-Duff
  64 compositing\cite{porter1984compositing} into a single image. This allows complex images to be formed from many simple pieces, as well
  65 as allowing for layered translucent objects, which would otherwise require the solution of some very complex constructive geometry problems.
  66
  67 While traditionally, rasterization was done entirely in software, modern computers and mobile devices have hardware support for rasterizing
  68 some basic primitives --- typically lines and triangles ---, designed for use rendering 3D scenes. This hardware is usually programmed with an
  69 API like \texttt{OpenGL}\cite{openglspec}.
  70
  71 More complex shapes like B\'ezier curves can be rendered by combining the use of bitmapped textures (possibly using signed-distance
  72 fields\cite{leymarie1992fast}\cite{frisken2000adaptively}\cite{green2007improved}) with polygons approximating the curve's shape\cite{loop2005resolution}\cite{loop2007rendering}.
  73
  74 Indeed, there are several implementations of entire vector graphics systems using OpenGL: OpenVG\cite{robart2009openvg} on top of OpenGL ES\cite{oh2007implementation};
  75 the Cairo\cite{worth2003xr} library, based around the PostScript/PDF rendering model, has the ``Glitz'' OpenGL backend\cite{nilsson2004glitz} and the SVG/PostScript GPU
  76 renderer by nVidia\cite{kilgard2012gpu} as an OpenGL extension\cite{kilgard300programming}.
  77
  78
  79 \section{Floating-Point Precision}
  80
  81 On modern computer architectures, there are two basic number formats supported:
  82 fixed-width integers and \emph{floating-point} numbers. Typically, computers
  83 natively support integers of up to 64 bits, capable of representing all integers
  84 between $0$ and $2^{64} - 1$\footnote{Most machines also support \emph{signed} integers,
  85 which have the same cardinality as their \emph{unsigned} counterparts, but which
  86 represent integers between $-(2^{63})$ and $2^{63} - 1$}.
  87
  88 Floating-point numbers\cite{goldberg1991whatevery} are the binary equivalent of scientific notation:
  89 each number consisting of an exponent ($e$) and a mantissa $(m)$ such that a number is given by
  90 \begin{equation}
  91         n = 2^{e} \times m
  92 \end{equation}
  93
  94 The IEEE 754 standard\cite{ieee754std1985} defines several floating-point data types
  95 which are used\footnote{Many systems' implement the IEEE 754 standard's storage formats,
  96 but do not implement arithmetic operations in accordance with this standard.} by most
  97 computer systems. The standard defines 32-bit (8-bit exponent, 23-bit mantissa) and
  98 64-bit (11-bit exponent, 53-bit mantissa) formats\footnote{The 2008
  99 revision to this standard\cite{ieee754std2008} adds some additional formats, but is
 100 less widely supported in hardware.}
 101
 102 How floating-point works and what its behaviour is w/r/t range and precision
 103 \cite{goldberg1991whatevery}
 104 \cite{goldberg1992thedesign}
 105
 106 Arb. precision exists
 107
 108 Higher precision numeric types can be implemented or used on the GPU, but are
 109 slow.
 110 \cite{emmart2010high}
 111
 112
 113
 114 \section{Quadtrees}
 115 The quadtree is a data structure which keeps
 116 \cite{finkel1974quad}
 117
 118 \begin{figure}[h]
 119         \includegraphics[width=0.4\linewidth]{figures/quadtree_example}
 120 \end{figure}
 121
 122
 123 \bibliographystyle{unsrt}
 124 \bibliography{papers}
 125
 126 \end{document}