precision in vector documents: a spatial approach · precision in vector documents: a spatial...

Precision in vector documentsa spatial approach

David Gow

This report is submitted as partial fulfilment ofthe requirements for the Software Engineering Programmme of the

School of Computer Science and Software EngineeringThe University of Western Australia

2014

David Gow (20513694)

Abstract

Despite being scalable vector images are typically specified and manipulated withfixed-precision numbers Existing formats therefore are unable to store documentswhich need greater precision and existing viewers perform coordinate system trans-forms at a fixed precision limiting the amount any document may be ldquozoomedrdquo

Using existing arbitrary-precision numeric types can resolve these issues butoften at a significant or infeasible performance penalty By taking into account thespatial nature of the data we can store and view documents to an arbitrary precisionwith little-to-no performance impact This is achieved by clipping the documentrsquosconstituent Bezier paths to nodes in a quadtree

In this paper we investigate the artefacts caused by lack of precision in documentformats and their viewers the realities of numeric types on modern hardware andpresent a new technique for efficiently rendering documents specified to an arbitraryprecision using a quadtree

A digital copy of this document with hyperlinks for your convenience is availableat httpdavidgownetDavidFYPThesispdf

Keywords document formats precision floating-point vector graphics beziercurves quadtree spatial SVG clipping OpenGL GPU

ii of 25


Acknowledgements

This work would not have been possible without the help and support of a great manypeople Firstly to Prof Tim French and Dr Rowan Davies for their neverendingsupport and encouragement throughout the course of this project To AsstProfWei Liu for coordinating the Software Engineering projects through a new set ofrules and processes without letting anyone get lost

To friends and family for always being there and for being so supportive andunderstanding through a very busy year

Finally to Sam Moore for his many contributions on what was definitely a teameffort Without his hard work insight and sense of humour there is no way thisproject could have been even half of what it became

To you all thank you

iii of 25


Contents

Abstract ii

Acknowledgements iii

1 Introduction 1

2 Background 2

21 Rendering 2

211 Rasterizing Vector Graphics 3

212 GPU Rendering 3

22 Numeric formats 4

23 Document Formats 6

231 A Taxonomy of Document formats 6

232 Precision in Document Formats 8

24 Quadtrees 9

3 IPDF A Document Precision Playground 11

31 GPU Floating Point Rounding Behaviour 12

32 Distortion and Quantisation at the limits of precision 13

4 View Reparenting and the Quadtree 15

41 Clipping cubic Beziers 16

42 Implementation Details 17

5 Experimental Results 18

6 Further Work and Conclusion 20

iv of 25


List of Figures

21 A circle as a vector image and a 32times 32 pixel raster image 2

22 The lifecycle of a document 6

23 A simple quadtree 9

31 The edges of a unit circle rendered with different hardware 13

32 Floating point errors affecting the rendering of an image 14

51 Time taken to render each frame while zooming in 18

52 Number of objects in the document while zooming in 19

61 A discontinuity at a node boundary 20

v of 25


CHAPTER 1

Introduction

Documents are an important part of day-to-day life we use them for business andpleasure to inform and entertain We often use images or diagrams to illustrate ourideas and to convey spatial or visual information

On the printed page there is a practical limit to the size and resolution of theseimages In order to store for example maps of large areas with fine detail we resortto an atlas splitting the map up into several pages each of which covers a differentpart of the map

With the advent of computers we can begin to alleviate these problems Thefixed size and resolution of the screen is worked around by having the screen bea viewport into a larger document letting the document be translated and zoomed(scaled to a particular magnification)

However limits in the range and precision of the numbers used to store andmanipulate documents restrict the size and zoom-level of documents While changingthe numeric types used can solve these issues here we investigate the use of a quadtreeto take advantage of the spatial nature of the data This is akin to maintaining theatlas of several different pages with different views of the map but with the advantageof greater ease-of-use and continuity

In chapter 3 we discuss work done in collaboration with Sam Moore[38] todevelop an environment for investigating the issues caused by lack of precision innumeric formats and how Graphics Processing Units handle the IEEE-754 floatingpoint standard[2]

1 of 25


CHAPTER 2

Background

21 Rendering

Computer graphics comes in two forms bit-mapped (or raster) graphics which isdefined by an array of pixel colours and vector graphics defined by mathematicaldescriptions of objects Bit-mapped graphics are well suited to photographs andmatch how cameras printers and monitors work

However bitmap devices do not handle zooming beyond their ldquonativerdquo resolution(the resolution where one document pixel maps to one display pixel) exhibiting anartefact called pixelation (see Figure 21) where the pixel structure becomes evidentAttempts to use interpolation to hide this effect are never entirely successful andsharp edges such as those found in text and diagrams are particularly affected

Vector graphics avoid many of these problems the representation is independentof the output resolution and rather a mathematical description of the shapes beingrendered Typically these shapes are simple geometric shapes like lines and arcs ormore complicated paths defined by curves

Vector Image Raster Image

Figure 21 A circle as a vector image and a 32times 32 pixel raster image

As existing displays (and printers) are bit-mapped devices vector documentsmust be rasterized into a bitmap at a given resolution The resulting bitmap isthen an approximation of the vector image at that resolution This bitmap is thendisplayed or printed

We will discuss the use of vector graphics as they lend themselves more natu-

2 of 25

21 RENDERING David Gow (20513694)

rally to scaling though many of the techniques will also apply to raster graphicsIndeed the use of quadtrees to compress bitmapped data is well established[47] andthe view-reparenting techniques have been used to facilitate an infinite zoom into a(procedurally generated) document[39]

211 Rasterizing Vector Graphics

Before a vector document can be rasterized the co-ordinates of any shapes must betransformed into screen space or viewport space[9] On a typical display many ofthese screen-space coordinates require very little precision or range However theco-ordinate transform must take care to ensure that precision is preserved duringthis transform

After this transformation the image is decomposed into its separate shapes whichare rasterized and then composited together Most graphics formats support Porter-Duff compositing[44] Porter-Duff compositing gives each element (typically a pixel)a ldquocoveragerdquo value denoted α which represents the contribution of that element tothe final scene Completely transparent elements would have an α value of 0 andcompletely opaque elements have an α value of 1 This permits arbitrary shapes tobe layered over one another in the raster domain while retaining soft-edges

The rasterization process may then proceed on one object (or shape) at a timeThere are special algorithms for rasterizing different shapes

Line Segment Straight lines between two points are easily rasterized using Bre-senhamrsquos algorithm[11] Bresenhamrsquos algorithm draws a pixel for every pointalong the long axis of the line moving one point along the short axis when theerror exceeds 1

2 a pixel

Bresenhamrsquos algorithm only operates on lines whose endpoints lie on integerpixel coordinates Due to this line ldquoclippingrdquo may be performed to find end-points of the line segment such that the entire line will be on-screen Howeverif line clipping is performed naıvely without also setting the error accumulatorcorrectly the linersquos slope will be altered slightly such that the slope becomesdependent on the viewport

Bezier Curve A Bezier curve is a smooth (ie infinitely differentiable) curve be-tween two points represented by a Bernstein polynomial The coefficients ofthis Bernstein polynomial are known as the ldquocontrol pointsrdquo

Bezier curves are typically rasterized using De Casteljaursquos algorithm[19] Linesegments are a first-order Bezier curve

212 GPU Rendering

While traditionally rasterization was done entirely in software modern computersand mobile devices have hardware support for rasterizing lines and triangles designedfor use rendering 3D scenes This hardware is usually programmed with an API likeOpenGL[49]

3 of 25

22 NUMERIC FORMATS David Gow (20513694)

More complex shapes like Bezier curves can be rendered by combining the use ofbitmapped textures (possibly using signed-distance fields[34 20 26]) stretched overa mesh of triangles approximating the curversquos shape[35][36]

Indeed there are several implementations of entire vector graphics systems usingOpenGL

bull The OpenVG standard[46] has been implemented on top of OpenGL ES[41]

bull the Cairo[50] library based around the PostScriptPDF rendering model hasthe ldquoGlitzrdquo OpenGL backend[40]

bull and the SVGPostScript GPU renderer by nVidia[31] as an OpenGL extension[30]

22 Numeric formats

On modern computer architectures there are two basic number formats supportedfixed-width integers and floating-point numbers Typically computers natively sup-port integers of up to 64 bits capable of representing all integers between 0 and264 minus 1 inclusive1

By introducing a fractional component (analogous to a decimal point) we canconvert integers to fixed-point numbers which have a more limited range but a fixedgreater precision For example a number in 44 fixed-point format would have fourbits representing the integer component and four bits representing the fractionalcomponent

0101︸︷︷︸integer component

1100︸︷︷︸fractional component

= 575 (21)

Floating-point numbers are a superset of scientific notation originally used bythe Babylonians (in base 60) perhaps as early as 1750 BC[24 33] Each number n(in a base β) consists of integers e (the exponent) and m (the mantissa) such that

n = βe timesmf (22)

Both e and m typically have a fixed width q and p respectively in base β Fornotational convenience we also represent m as a fraction mf = βminuspm so |mf | lt 1We further call a floating point number normalised if the first digit of m is nonzeroThe exponent e is usually allowed to be either positive or negative (either by havinga sign bit or being offset a fixed amount) The value of a floating point numbern must therefore be minusβemax lt n lt βemax The smallest possible magnitude ofa normalised floating point number is βeminminus1 as mf must be at least 01 Non-normalised numbers may represent 0 and many normalised floating-point includezero in some way too

The IEEE 754 standard[1] defines several floating-point data types which areused2 by most computer systems The standard defines 32-bit (8-bit exponent 23-bit mantissa 1 sign bit) and 64-bit (11-bit exponent 53-bit mantissa 1 sign bit)

1Most machines also support signed integers which have the same cardinality as their unsignedcounterparts but which represent integers in the range [minus(263) 263 minus 1]

2Many systems implement the IEEE 754 standardrsquos storage formats but do not implementarithmetic operations in accordance with this standard[49 29]

4 of 25


formats3 which can store approximately 7 and 15 decimal digits of precision re-spectively The IEEE 754 standard also introduces an implicit 1 bit in the mostsignificant place of the mantissa when the exponent is not emin

Floating-point numbers behave quite differently to integers or fixed-point num-bers as the representable numbers are not evenly distributed Large numbers arestored to a lesser precision than numbers close to zero This can present problems indocuments when zooming in on objects far from the origin Furthermore due to thelimited precision and the different ldquoalignmentrdquo of operands in arithmetic severalof algebraic properties of rings we take for granted in the integers do not hold forfloating point numbers including the property of assosciativity[33]

IEEE floating-point has some interesting features as well including values fornegative zero positive and negative infinity the ldquoNot a Numberrdquo (NaN) value andsubnormal values which trade precision for range when dealing with very smallnumbers by not normalising numbers when the exponent is emin Indeed with thesevalues IEEE 754 floating-point equality does not form an equivalence relation whichcan cause issues when not considered carefully[23]

There also exist formats for storing numbers with arbitrary precision andorrange Some programming languages support ldquobig integerrdquo[43] types which can rep-resent any integer that can fit in the systemrsquos memory Similarly there are arbitrary-precision floating-point data types[42][37] which can represent any number of theform

n

2dn d isin Z (23)

These types are typically built from several native data types such as integers andfloats paired with custom routines implementing arithmetic primitives[45] Opera-tions on these types therefore are usually slower than those performed on nativetypes

Pairs of integers (a isin Z b isin Z 0) can be used to represent rationals This allowsvalues such as 1

3 to be represented exactly whereas in fixed or floating-point formatsthis would have a recurring representation

0︸︷︷︸integer part

01︸︷︷︸recurring part

01 01 01 (24)

Whereas with a rational type this is simply 13 Rationals do not have a unique

representation for each value typically the reduced fraction is used as a characteristicelement

While traditionally GPUs have supported some approximation of IEEE 754rsquos 32-bit floats modern graphics processors also support 16-bit[12] and 64-bit[13] IEEEfloats though some features of IEEE floats like denormals and NaNs are not alwayssupported Note however that some parts of the GPU are not able to use all formatsso precision will likely be truncated at some point before display Higher precisionnumeric types can be implemented or used on the GPU but are slow[17]

3The 2008 revision to this standard[2] adds some additional formats but is less widely supportedin hardware

5 of 25

23 DOCUMENT FORMATS David Gow (20513694)

DocumentDescription

TypesetDocument

ImageLayout Render

Figure 22 The lifecycle of a document

23 Document Formats

Most existing document formats such as the venerable PostScript and PDF aredesigned to imitate existing paper documents largely to allow for easy printing Inorder to truly take advantage of the possibilities that operating in the digital domainopens up to us we must look to new formats

Formats such as HTML allow for a greater scope of interactivity and for a moredata-driven model allowing the content of the document to be explored in waysthat perhaps the author had not anticipated[27] However these data-driven for-mats typically do not support fixed layouts and the display differs from renderer torenderer

231 A Taxonomy of Document formats

The process of creating and displaying a document is a consistent (Figure 22) thoughdifferent document formats approach it slightly differently A document often beginsas raw content text and images (be they raster or vector) and it must end up as astream of photons flying towards the readerrsquos eyes

There are two fundamental stages (as shown in Figure 22) by which all docu-ments digital or otherwise are produced and displayed layout and rendering Thelayout stage is where the positions and sizes of text and other graphics are deter-mined The text will be flowed around graphics the positions of individual glyphswill be placed ensuring that there is no undesired overlap and that everything willfit on the page or screen

The rendering stage actually produces the final output whether as ink on paperor pixels on a computer monitor Each graphical element is rasterized and compositedinto a single image of the target resolution

Different document formats represent documents in different stages of this pro-cess Bitmapped images for example would represent the output of the final stageof the process whereas markup languages typically specify a document which hasnot yet been processed ready for the layout stage

Furthermore some document formats treat the document as a program written ina (usually Turing complete) document language with instructions which emit shapesto be displayed These shapes are either displayed immediately as in PostScript orstored in another file such as with TEXor LATEX which emit a DVI file Most otherforms of document use a Document Object Model being a list or tree of objects to be

6 of 25


rendered DVI PDF HTML4 and SVG[15] Of these only HTML and TEXtypically storedocuments in pre-layout stages whereas even Turing complete document formatssuch as PostScript typically encode documents which already have their elementsplaced

TEX and LATEX Donald Knuthrsquos typesetting language TEX is one of the oldercomputer typesetting systems originally conceived in 1977[32] It implementsa Turing-complete language and is human-readable and writable and is stillpopular due to its excellent support for typesetting mathematics TEXonlyimplements the ldquolayoutrdquo stage of document display and produces a typesetfile traditionally in DVI format though modern implementations will oftentarget PDF instead

This document was prepared in LATEX 2ε

DVI TEX traditionally outputs to the DVI (ldquoDeVice Independentrdquo) format a binaryformat which consists of a simple stack machine with instructions for drawingglyphs and curves[21]

A DVI file is a representation of a document which has been typeset and DVI

viewers will rasterize this for display or printing or convert it to another similarformat like PostScript to be rasterized

HTML The Hypertext Markup Language (HTML)[8] is the widely used documentformat which underpins the world wide web In order for web pages to adaptappropriately to different devices the HTML format simply defined semanticparts of a document such as headings phrases requiring emphasis referencesto images or links to other pages leaving the layout up to the browser whichwould also rasterize the final document

The HTML format has changed significantly since its introduction and most ofthe layout and styling is now controlled by a set of style sheets in the CSS[10]format

PostScript Much like DVI PostScript[3] is a stack-based format for drawing vec-tor graphics though unlike DVI (but like TEX) PostScript is text-based andTuring complete PostScript was traditionally run on a control board in laserprinters rasterizing pages at high resolution to be printed though PostScriptinterpreters for desktop systems also exist and are often used with printerswhich do not support PostScript natively[5]

PostScript programs typically embody documents which have been typesetthough as a Turing-complete language some layout can be performed by thedocument

PDF Adobersquos Portable Document Format (PDF)[4] takes the PostScript renderingmodel but does not implement a Turing-complete language Later versions ofPDF also extend the PostScript rendering model to support translucent regionsvia Porter-Duff compositing[44]

PDF documents represent a particular layout and must be rasterized beforedisplay

4Some of these formats mdash most notably HTML mdash implement a scripting lanugage such asJavaScript which permit the DOM to be modified while the document is being viewed

7 of 25


Document Description Typeset DocumentProgrammed TEX Postscript DVIObject Model HTML PDF SVG

Table 21 Classifying document formats

SVG Scalable Vector Graphics (SVG) is a vector graphics document format[15]which uses the Document Object Model It consists of a tree of matrix trans-forms with objects such as vector paths (made up of Bezier curves) and textat the leaves

By looking both at what is being represented (which stage of the process inFigure 22 the document is in) and how it is being represented (as either a setof instructions or a list of objects) The classification of the formats listed aboveaccording to these criteria is shown in Table 21

232 Precision in Document Formats

Most existing document formats were designed to represent documents to be printedon paper which of course has limited size and resolution Because of this thesedocument formats typically use numeric types which can only represent a fixed rangeand precision While this works fine with printed pages users reading documentson computer screens using programs with ldquozoomrdquo functionality are prevented fromworking beyond a limited scale factor lest artefacts appear due to issues with numericprecision

TEXuses a 1416 bit fixed point type (implemented as a 32-bit integer type withone sign bit and one bit used to detect overflow)[6] This can represent values in therange [minus(214) 214 minus 1] with 16 binary digits of fractional precision

The DVI files TEX produces may use ldquoup tordquo 32-bit signed integers[21] to specifythe document but there is no requirement that implementations support the full32-bit type It would be permissible for example to have a DVI viewer supportonly 24-bit signed integers though many files which require greater range may failto render correctly

PostScript[3] supports two different numeric types integers and reals both ofwhich are specified as strings The interpreterrsquos representation of numbers is notexposed though the representation of integers can be determined by a programthrough the use of bitwise operations The PostScript specification lists some ldquotypicallimitsrdquo of numeric types though the exact limits may differ from implementation toimplementation Integers typically must fall in the range [minus231 231 minus 1] and realsare listed to have largest and smallest values of plusmn1038 values closest to 0 of plusmn10minus38

and approximately 8 decimal digits of precision derived from the IEEE 754 single-precision floating-point specification

Similarly the PDF specification[4] stores integers and reals as strings though ina more restricted format than PostScript The PDF specification gives limits for theinternal representation of values Integer limits have not changed from the PostScript

8 of 25

24 QUADTREES David Gow (20513694)

specification but numbers representable with the real type have been specified dif-ferently the largest representable values are plusmn3403 times 1038 the smallest non-zerorepresentable values are plusmn1175times 10minus38 with approximately 5 decimal digits of pre-cision in the fractional part5 Adobersquos implementation of PDF uses both IEEE 754single precision floating-point numbers and (for some calculations and in previousversions) 1616 bit fixed-point values

The SVG specification[15] specifies numbers as strings with a decimal represen-tation of the number It is stated that a ldquoConforming SVG Viewerrdquo must have ldquoallvisual rendering accurate to within one device pixel to the mathematically correctresult at the initial 11 zoom ratiordquo and that ldquoit is suggested that viewers attempt tokeep a high degree of accuracy when zoomingrdquo A ldquoConforming High-Quality SVGViewerrdquo must use ldquodouble-precision floating point6rdquo for computations involving co-ordinate system transformations

24 Quadtrees

When viewing or processing a small part of a large document it may be helpful tonot process (or cull) parts of the document which are off-screen

Figure 23 A simple quadtree

The quadtree[18]is a data structure (one of a family of spatial data structures)which recursively breaks down space into smaller subregions which can be processedindependently Points (or other objects) are added to a single node which (if certaincriteria are met) is split into four equal-sized subregions and points attached to theregion which contains them

Quadtrees have long been used in computer graphics for both culling (excludingobjects in nodes which are not visible) and ldquolevel of detailrdquo where different levels ofthe quadtree store versions of the same space at different qualities or resolutions[51]

Other spatial data structures exist such as the KD-tree[7] which partitions thespace on any axis-aligned line or the BSP tree[22] which splits along an arbitraryline which need not be axis aligned We believe however that the simpler conversion

5The PDF specification mistakenly leaves out the negative in the exponent here6Presumably the 64-bit IEEE 754 ldquodoublerdquo type

9 of 25


from binary coordinates to the quadtreersquos binary split make it a better avenue forinitial research to explore

We will investigate how the quadtree can be used to preserve coordinate precisionin more detail in chapter 4

10 of 25


CHAPTER 3

IPDF A Document PrecisionPlayground

In collaboration with Sam Moore[38] to investigate the precision issues present indocument formats and viewers we developed a document viewer IPDF IPDF is a C++

program which supports rendering both TrueType font outlines and a subset of theSVG format providing scripting and performance analysis tools Several techniquesfor working with documents specified with arbitrary precision were implemented inthis program

The source code to IPDF is available at httpgituccasnaup=ipdfcodegita=tree with a mirror (including more detailed development statistics) locatedat httpsgithubcomszmooreipdf-code

At its core IPDF breaks documents down into a set of objects each with rectan-gular bounds (x y w h) and with one of several types

1 Rectangle A simple axis-aligned rectangle (either filled with a solid colouror left as an outline) covering the object bounds

2 Ellipse A filled axis-aligned ellipse rendered parametrically to expose thelimits of GPU precision

3 Bezier Curve A cubic Bezier curve Bezier curve control points are storedrelative to the coordinate system provided by the object bounds and severalobjects can share the same set of coefficients but with different bounds

IPDF can be compiled using different number representations not only to allowfor comparison between different-precision floating point numbers but also arbitrary-precision types such as rationals In addition IPDF has its own implementations ofarbitrary-precision integers and rationals or may use those provided by the GNUMultiple Precision Arithmetic Library[25] (GMP)

Documents in IPDF may be rendered either on the CPU using a custom softwarerasterizer built on the numeric types supported or on the GPU with OpenGL 32fragment and geometry shaders using the GPUrsquos default numeric representationAdditionally when the GPU is used coordinate system transforms may be run eitheron the GPU or on the CPU using the full numerical precision specified

Furthermore IPDF allows SVG files (and text rendered with TrueType fonts) tobe inserted at any point and scale in the document allowing for the same images

11 of 25

31 GPU FLOATING POINT ROUNDING BEHAVIOUR David Gow (20513694)

to be compared at different scales Any paths specified in input files may have theirbounding boxes calculated before being split into individual curves which each havetheir own bounding boxes[38]

31 GPU Floating Point Rounding Behaviour

While the IEEE-754 standard specifies both the format of floating-point numbers andthe operations they perform However the OpenGL specification[49] while requiringthe same basic format for single-precision floats neither specifies the behaviour ofdenormals nor requires any support for NaN or infinite values Similarly no supportfor floating point exceptions is required with the note that no operation should everhalt the GPU

However an extension to the specification GL ARB shader precision[29] in 2010allows programs to require stricter precision requirements Notably support forinfinite values is required and maximum relative error in ULPs

Different GPU vendors and drivers have different rounding behaviour and mosthardware (both CPU and GPU) provides ways of disabling support for some IEEEfeatures to improve performance[28 16]

Many GPUs now support double-precision floating-point numbers1 as specifiedin the GL ARB gpu shader fp64[13] OpenGL extension However many of the fixed-function parts of the GPU do not support double-precision floats making it imprac-tical to use them

To see the issues we rendered the edge of a circle (calculated by discardingpixels with x2 + y2 gt 1) on several GPUs as well as an x86-64 CPU as seen inFigure 31 Of these the nVidia GPU came closest to the CPU rendering whereasIntelrsquos hardware clearly performs some optimisation which produces quite differentartefacts The diagonal distortion in the AMD rendering may be a result of differentrounding across the two triangles across which the circle was rendered

1Some drivers however do not yet support this feature including one of our test machines

12 of 25

32 DISTORTION AND QUANTISATION AT THE LIMITS OF PRECISIONDavid Gow (20513694)

x86-64 CPU nVidia shader

fglrx shader intel shader

Figure 31 The edges of a unit circle rendered with different hardware

32 Distortion and Quantisation at the limits of precision

When trying to insert fine detail into a document using fixed-width floats someprecision is lost In particular the control points of the curves making up the imageget rounded to the nearest2 representable point Figure 32 shows what happens

2Other rounding modes are available but they all suffer from similar artefacts

13 of 25


when an image is small enough to be affected by this quantisation The grid structurebecomes very apparent

(a) Intended rendering (b) With artefacts

Figure 32 Floating point errors affecting the rendering of an image

These artefacts also become prevalent when an object is far from the origin asmore bits would be required to store the position so the lower order bits of theposition must be discarded As the position of the viewport and the object willshare many of the same initial digits catastrophic cancellation[23] can occur

14 of 25


CHAPTER 4

View Reparenting and the Quadtree

One of the important parts of document rendering is that of coordinate transforms

Traditionally the document exists in its own coordinate system b We thendefine a coordinate system v to represent the view

To eliminate visible error due to floating point precision we need to ensure thatany point (including control points) must be representable as a float both in thedocument and in view coordinates ie

1 have a limited magnitude

2 be precise enough to uniquely identify a pixel on the display

Despite a point not being representable with floats in one coordinate system itmay be representable in another We can therefore split a document up into severalcoordinate systems such that each point is completely representable

Similarly the points making up the visible document all need to be representable(to at least one pixel of precision) To achieve this we use a quadtree where eachnode stores points within its bounds in its own coordinate system Objects whichspan multiple nodes are clipped such that no points1 lie outside the quadtree node

Setting aside the possibility that an object might span multiple nodes for thetime being letrsquos investigate how the coordinates of a point are affected by placing itin the quadtree

Suppose p = (px py) is a point in a global document coordinate system whichwersquoll consider the root node of our quadtree px and py are represented by a finitelist of binary digits x0 xn y0 yn Consider now the pair (x0 y0)

x0 =

0 if px is in the left half of d

1 if px is in the right half of d

y0 =

0 if py is in the bottom half of d

1 if py is in the top half of d

We have therefore found which child node of our quadtree contains p The coordi-nates of p within that node are (x1 xn y1 yn) By the principle of mathematicalinduction we can repeat the process to move more bits from the coordinates of p

1except some control points

15 of 25

41 CLIPPING CUBIC BEZIERS David Gow (20513694)

into the structure of the quadtree until the remaining coordinates may be preciselyrepresented

This implies that the quadtree is equivalent to an arbitrary precision integerdatatype By reversing the process any point representable in the quadtree can bestored as a fixed-length bit string

Furthermore we can get approximations of points by inserting them into higherlevels of the quadtree with their coordinates rounded By then viewing the documentat a certain level of the quadtree we then not only do not need to consider bits ofprecision which are not required to represent the point to pixel resolution we canalso cull objects outside the visible nodes at that level

Indeed we can guarantee that by selecting the level of the quadtree we view suchthat the view width and height lie within the range (05 1] we can ensure that atmost four nodes need to be rendered

41 Clipping cubic Beziers

In order to ensure that the quadtree maintains precision in this fashion we need toensure that all objects are entirely contained within a quadtree node This is notalways the case and indeed when zooming in on any object eventually the objectwill span multiple quadtree nodes 2

We therefore need a way to subdivide objects into several new objects each ofwhich is contained within one node To do this we need to clip the cubic Beziercurves from which our document is formed to fit within a rectangle

Cubic Bezier curves are defined parametrically as two cubics x(t) and y(t) with0 le t le 1 We clip these to a rectangular bounding box in stages We first findthe intersections of the curve with the clipping rectangle by finding the roots3 of thecubic shifted to match the corners of the rectangle This produces some spuriouspoints as it assumes the edges of the clipping rectangle are lines with infinite extentbut this at worst introduces some minor inefficiency in the process and does notaffect the result

Once the values of the parameter t which intersect the clipping rectangle havebeen determined the curve is split into segments To do this the values 0 and 1(representing the endpoints) are added to the list of intersecting t values which isthen sorted Adjacent values t0 and t1 form a segment The midpoint of that segment(with the value t0+t1

2 ) is evaluated and if it falls outside the clipping rectangle thesegment is discarded

Finally the segments are re-parametrised by subdividing the curve using DeCasteljaursquos algorithm[48] By re-parameterising the curves such that 0 le t le 1we ensure that the first and last coefficients have the endpointsrsquo coodinates andtherefore lie in the quadtree node

2Assuming the objectrsquos size is nonzero We can show this in one dimension by relying on thefact that given (a b) isin R exist binary fraction c such that a lt c lt b

3While there is a method for solving cubics exactly[14] we instead use numeric methods to avoidthe need for square root operations which cannot be done exactly on some of the numeric types weused

16 of 25

42 IMPLEMENTATION DETAILS David Gow (20513694)

By the definition of De Casteljaursquos algorithm[19] the control points are beingldquodraggedrdquo by means of weighted average away from the portion of the curve thathas been clipped It follows naturally that the new control points must be inside theconvex hull of the original points Unfortunately time constraints did not permit usto formally prove that the locations of these points will always be constricted enoughto ensure that the required precision is kept We hope that further work in this areamay result in a similar conjecture being proved (chapter 6)

42 Implementation Details

Our implementation of the quadtree is built on top of our existing document imple-mentation which provides an array of objects For each quadtree node we then storethe range of object IDs belonging to the node along with pointers to the parent nodeand any extant child nodes This has some flaws notably the mutation of all nodesbut the last is impossible without renumbering all later objects so each node has apointer to the ldquonext overlayrdquo a node which simply acts as a container for anotherrange of objects Essentially this is a linked-list of object ID ranges per node all ofwhich are rendered Unfortunately this lets the quadtree become fragmented shouldobjects be added at runtime particularly because every object must be propagatedand clipped to all parent and child nodes

For performance reasons objects are not propagated up the tree if they wouldbecome too small to represent

17 of 25


CHAPTER 5

Experimental Results

To determine if the quadtree actually gave a performance improvement we comparedit to a naıve implementation of aribitrary precision using the rational type from theGNU Multiprecision library (GMP)[25]

0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)

QuadtreeGMP Rationals

(a) Logarithmic time

0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time

Figure 51 Time taken to render each frame while zooming in

An 800 frame test script was developed which would steadily zoom in on a gridThis was then run both with the quadtree and GMP rationals and the time takenper frame was measured As can be seen in Figure 51 the quadtree is during thistest significantly faster

First we notice that GMP rationals are slowing down considerably as we zoomin This is a result of the size of the numerator and denominator growing as the viewbounds change While rationals are simplified after each operation it is likely1 to seethe result require more memory (and therefore time spent performing calculations)than the operands As the bounds accumulate changes over time as the document ismanipulated this grows unboundedly

The performance characteristics of the quadtree are also interesting The numberof quadtree nodes we render has an obvious upper bound of 4 with the size of anode strictly greater than the size of the the view at most one ldquoedgerdquo can appearalong each axis While each of these quadtree nodes can have more objects thantheir parents (should many of the curves intersect the boundaries of the node several

1The probability that two integers are coprime is 1ζ(2)

= 6π2 asymp 61 (where ζ is the Riemann

Zeta Function) so it is more likely than not that a randomly selected numerator and denominatorwill not simplify It would be interesting to see if the nature of the basic operations on rationalsaffect this probability significantly

18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts

In DocumentRenderedIn Original Document

Figure 52 Number of objects in the document while zooming in

times) in most common usage this is unlikely In most cases as seen in Figure 52the number of objects being rendered decreases as more and more objects are culledIt is not unreasonable to expect therefore that the quadtree may even improveperformance over simple document formats with only finite precision support witha large number of distributed objects

Prevalent in Figure 51 are regular spikes in the quadtree performance Theseshow the generation of new quadtree nodes as required The time taken to generatethese new nodes decreases with the number of objects in the nodes In this test 237of rendering time was spent generating a total of 219 new nodes which required thecreation of 6559 new objects

Note that after a lot of view manipulation the number of nodes (and henceobjects) can escalate significantly This can on complex documents cause significantmemory pressure in our implementation Though we did not investigate methods ofreducing the memory consumption of the quadtree we have no reason to believe itto be infeasible

As a final note an issue with the implementation resulted in the creation of newnodes sometimes spanning multiple frames leaving a ldquoflickeringrdquo effect as some nodeswere not rendered This is evident in Figure 52 as slight ldquodipsrdquo in the number ofobjects rendered We do not believe that this bug has any significant effect on theconclusions we have drawn

19 of 25


CHAPTER 6

Further Work and Conclusion

The use of spatial data structures to specify documents with arbitrary precision hasbeen validated as a viable alternative to the use of arbitrary precision numeric typeswhere an arbitrary (rather than infinite) amount of precision is needed Once con-structed they are faster in many circumstances and the structure can also be usedfor culling When the viewport moves and scales smoothly the cost of construct-ing new nodes is amortised over the movement Unfortunately we were unable toimplement interactive modification or production of documents in this format andsuspect that our implementation is not well suited to being adapted to this task

Memory usage could be reduced and performance increased by tagging nodeswhich do not contain any new information and garbage-collecting them when theyare no-longer in view Similarly it would be interesting to investigate efficient meansof serialising these quadtrees

Figure 61 A discontinuity at a node boundary

Handling the edge cases where objects have been split across nodes can causediscontinuities in our implementation as shown in Figure 61 While such discontinu-ities can be made arbitrarily small when specifying the document continuity when

20 of 25


zooming beyond that point could be desirable in many fields It would be interest-ing to see if always providing a slight ldquobuffer zonerdquo outside the node when clippingallowing the ends of curves to overlap would result in any artefacts Alternativelyendpoints could be forced to lie exactly on quadtree node boundaries regardless oferror in the root finding and curves could be ldquojoinedrdquo by storing information aboutwhere curves originated

Using floating-point numbers within the quadtree greatly complicates the math-ematics involved in proving that the precision of Bezier curves is maintained whenbeing clipped to the quadtree We would advise further work investigate the use ofa fixed-point type for coordinates within the quadtree which would greatly simplifyanalysis of the structurersquos properties and remove needless complexity

Implementing the remaining parts of the SVG specification would present severalother challenges Features like shading (using for example Loop-Blinn[35 36]) wouldrequire filled objects be clipped to nodes in a way that preserves the topology of theclipped object

Furthermore the SVG format can represent recursive and mutually-recursive struc-tures No known implementations correctly support these and it would be interestingto attempt to render self-similar or fractal objects using this functionality

21 of 25


Bibliography

[1] IEEE standard for binary floating-point arithmetic ANSIIEEE Std 754-1985(1985)

[2] IEEE standard for floating-point arithmetic IEEE Std 754-2008 (Aug 2008)1ndash70

[3] Adobe Systems Incorporated PostScript Language Reference 3rd edAddison-Wesley Publishing Company 1985 - 1999

[4] Adobe Systems Incorporated PDF Reference 6th ed Adobe SystemsIncorporated 2006

[5] Artifex Software Ghostscript an interpreter for the postscript languageand pdf httpwwwghostscriptcom 1988 Retrieved 2014-05-21

[6] Beebe N Extending TEX and METAFONT with floating-point arithmeticTUGboat 28 3 (2007)

[7] Bentley J L Multidimensional binary search trees used for associativesearching Commun ACM 18 9 (Sept 1975) 509ndash517

[8] Berners-Lee T and Connolly D Hypertext markup language ndash 20Internet RFC 1866 (1995)

[9] Blinn J A trip down the graphics pipeline Grandpa what does ldquoviewportrdquomean Computer Graphics and Applications IEEE 12 1 (Jan 1992) 83ndash87

[10] Bos B Wium Lie H Lilley C and Ian J Cascading style sheets level2 CSS2 specification httpwwww3orgTR1998REC-CSS2-19980512Retrieved 2014-05-22

[11] Bresenham J E Algorithm for computer control of a digital plotter IBMSystems journal 4 1 (1965) 25ndash30

[12] Brown P NV half float httpwwwopenglorgregistryspecsNV

half_floattxt 2002 Retrieved 2014-05-20

[13] Brown P Lichtenbelt B Licea-Kane B Merry B Dodd CWerness E Sellers G Roth G Bolz J Haemel N Boudier Pand Daniell P ARB gpu shader fp64 httpwwwopenglorgregistryspecsARBgpu_shader_fp64txt 2010 Retrieved 2014-05-20

[14] Cardano G Artis magnae sive de regulis agebraicis liber unus 1545

[15] Dahlstom E Dengler P Grasso A Lilley C McCormack CSchepers D Watt J Ferraiolo J Jun F and Jackson D Scal-able vector graphics (svg) 11 (second edition) W3C Recommendation (August2011) Retrieved 2014-05-23

22 of 25

BIBLIOGRAPHY David Gow (20513694)

[16] Dawson B Thatrsquos Not Normal mdash the Performance ofOdd Floats httpsrandomasciiwordpresscom20120520

thats-not-normalthe-performance-of-odd-floats accessed 2014-10-18 2012

[17] Emmart N and Weems C High precision integer multiplication with agraphics processing unit In 2010 IEEE International Symposium on Parallel ampDistributed Processing Workshops and Phd Forum (IPDPSW) (2010) IEEEpp 1ndash6

[18] Finkel R A and Bentley J L Quad trees a data structure for retrievalon composite keys Acta informatica 4 1 (1974) 1ndash9

[19] Foley J Computer Graphics Principles and Practice Addison-Wesley sys-tems programming series Addison-Wesley 1996

[20] Frisken S F Perry R N Rockwood A P and Jones T R Adap-tively sampled distance fields a general representation of shape for computergraphics In Proceedings of the 27th annual conference on Computer graphicsand interactive techniques (2000) ACM PressAddison-Wesley Publishing Copp 249ndash254

[21] Fuchs D The format of TEXrsquos DVI files TUGBoat 3 2 (1982)

[22] Fuchs H Kedem Z M and Naylor B F On visible surface generationby a priori tree structures In Proceedings of the 7th Annual Conference onComputer Graphics and Interactive Techniques (New York NY USA 1980)SIGGRAPH rsquo80 ACM pp 124ndash133

[23] Goldberg D What every computer scientist should know about floating-pointarithmetic ACM Comput Surv 23 1 (Mar 1991) 5ndash48

[24] Goldberg D The design of floating-point data types ACM Lett ProgramLang Syst 1 2 (June 1992) 138ndash151

[25] Granlund T et al The GNU Multiple Precision Arithmetic Libraryhttpsgmpliborg accessed 2014-07-07 The Free Software Foundation

[26] Green C Improved alpha-tested magnification for vector textures and specialeffects In ACM SIGGRAPH 2007 courses (2007) ACM pp 9ndash18

[27] Hayes B Pixels or perish American Scientist 100 2 (2012) 106 ndash 111

[28] Intel Corporation 3DMedia mdash 3D Pipeline (Ivy Bridge) Intel OpenSourceHD Graphics Programmerrsquos Reference Manual (PRM) 2 1 (2012)

[29] Kessenich J GL ARB shader precision httpswwwopenglorg

registryspecsARBshader_precisiontxt accessed 2014-10-17 2010

[30] Kilgard M J Programming with NV path rendering An annex to theSIGGRAPH paper GPU-accelerated path rendering heart 300 300

[31] Kilgard M J and Bolz J GPU-accelerated path rendering ACM Trans-actions on Graphics (TOG) 31 6 (2012) 172

23 of 25


[32] Knuth D Preliminary preliminary description of TEX httpwww

saildartorgTEXDRAFT[1DEK]1 1977 Retrieved 2014-05-20

[33] Knuth D Seminumerical Algorithms 3rd ed vol 2 of The Art of ComputerProgramming AddisonndashWesley 1998

[34] Leymarie F and Levine M D Fast raster scan distance propagation onthe discrete rectangular lattice CVGIP Image Understanding 55 1 (1992)84ndash94

[35] Loop C and Blinn J Resolution independent curve rendering using pro-grammable graphics hardware ACM Transactions on Graphics (TOG) 24 3(2005) 1000ndash1009

[36] Loop C and Blinn J Rendering vector art on the gpu GPU gems 3(2007) 543ndash562

[37] Maddock J and Kormanyos C Boost multiprecision li-brary httpwwwboostorgdoclibs1_53_0libsmultiprecision

dochtmlboost_multiprecision

[38] Moore S Number representation and precision in vector graphics http

szmoorenetipdfsamthesispdf 2014

[39] Munroe R Pixels httpxkcdcom1416 accessed 2014-09-03

[40] Nilsson P and Reveman D Glitz Hardware accelerated image composit-ing using OpenGL In USENIX Annual Technical Conference FREENIX Track(2004) pp 29ndash40

[41] Oh A Sung H Lee H Kim K and Baek N Implementation ofOpenVG 10 using OpenGL ES In Proceedings of the 9th international confer-ence on Human computer interaction with mobile devices and services (2007)ACM pp 326ndash328

[42] Oracle Corporation javamathBigDecimal httpdocsoraclecom

javase7docsapijavamathBigDecimalhtml Retrieved 2014-05-19

[43] Oracle Corporation javamathBigInteger httpdocsoraclecom

javase6docsapijavamathBigIntegerhtml Retrieved 2014-05-19

[44] Porter T and Duff T Compositing digital images In ACM SIGGRAPHComputer Graphics (1984) vol 18 ACM pp 253ndash259

[45] Priest D Algorithms for arbitrary precision floating point arithmetic InComputer Arithmetic 1991 Proceedings 10th IEEE Symposium on (Jun 1991)pp 132ndash143

[46] Robart M OpenVG paint subsystem over OpenGL ES shaders In ConsumerElectronics 2009 ICCErsquo09 Digest of Technical Papers International Confer-ence on (2009) IEEE pp 1ndash2

[47] Salomon D Motta G and Bryant D Data Compression The Com-plete Reference Molecular biology intelligence unit Springer 2007

24 of 25


[48] Sederberg T W Computer aided geometric design course notes 2007

[49] Segal M Akely K and Leech J The OpenGL RcopyGraphics System ASpecification The Kronos Group Inc 2014

[50] Worth C and Packard K Xr Cross-device rendering for vector graphicsIn Linux Symposium (2003) p 480

[51] Zerbst S and Duvel O 3D Game Engine Programming Premier Press2004

25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering

Rasterizing Vector Graphics

GPU Rendering

Numeric formats

Document Formats

A Taxonomy of Document formats

Precision in Document Formats

Quadtrees

IPDF A Document Precision Playground

GPU Floating Point Rounding Behaviour

Distortion and Quantisation at the limits of precision


Clipping cubic Beacuteziers

Implementation Details




Abstract

Despite being scalable vector images are typically specified and manipulated withfixed-precision numbers Existing formats therefore are unable to store documentswhich need greater precision and existing viewers perform coordinate system trans-forms at a fixed precision limiting the amount any document may be ldquozoomedrdquo

Using existing arbitrary-precision numeric types can resolve these issues butoften at a significant or infeasible performance penalty By taking into account thespatial nature of the data we can store and view documents to an arbitrary precisionwith little-to-no performance impact This is achieved by clipping the documentrsquosconstituent Bezier paths to nodes in a quadtree

In this paper we investigate the artefacts caused by lack of precision in documentformats and their viewers the realities of numeric types on modern hardware andpresent a new technique for efficiently rendering documents specified to an arbitraryprecision using a quadtree

A digital copy of this document with hyperlinks for your convenience is availableat httpdavidgownetDavidFYPThesispdf

Keywords document formats precision floating-point vector graphics beziercurves quadtree spatial SVG clipping OpenGL GPU

ii of 25


Acknowledgements





iii of 25


Contents

Abstract ii


1 Introduction 1

2 Background 2

21 Rendering 2


212 GPU Rendering 3





24 Quadtrees 9









iv of 25


List of Figures









v of 25


CHAPTER 1

Introduction






1 of 25


CHAPTER 2

Background

21 Rendering








2 of 25








2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










Acknowledgements





iii of 25


Contents

Abstract ii


1 Introduction 1

2 Background 2

21 Rendering 2


212 GPU Rendering 3





24 Quadtrees 9









iv of 25


List of Figures









v of 25


CHAPTER 1

Introduction






1 of 25


CHAPTER 2

Background

21 Rendering








2 of 25








2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










Contents

Abstract ii


1 Introduction 1

2 Background 2

21 Rendering 2


212 GPU Rendering 3





24 Quadtrees 9









iv of 25


List of Figures









v of 25


CHAPTER 1

Introduction






1 of 25


CHAPTER 2

Background

21 Rendering








2 of 25








2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










List of Figures









v of 25


CHAPTER 1

Introduction






1 of 25


CHAPTER 2

Background

21 Rendering








2 of 25








2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










CHAPTER 1

Introduction






1 of 25


CHAPTER 2

Background

21 Rendering








2 of 25








2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










CHAPTER 2

Background

21 Rendering








2 of 25








2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees
















2 a pixel




212 GPU Rendering


3 of 25







22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees















22 Numeric formats





= 575 (21)







4 of 25






n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees














n

2dn d isin Z (23)






01 01 01 (24)





5 of 25


DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










DocumentDescription

TypesetDocument

ImageLayout Render


23 Document Formats









6 of 25















7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees























7 of 25













8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees





















8 of 25




24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees












24 Quadtrees







9 of 25




10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees












10 of 25


CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










CHAPTER 3












11 of 25










12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees


















12 of 25








13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees
















13 of 25






14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees














14 of 25


CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










CHAPTER 4











x0 =



y0 =





15 of 25















16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees























16 of 25






17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees














17 of 25


CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










CHAPTER 5



0 100 200 300 400 500 600 700 800Frame

100

101

102

103

104

Tim

e (m

s)



0 100 200 300 400 500 600 700 800Frame

0

50

100

150

200Ti

me

(ms)

Quadtree

(b) Linear time








18 of 25


0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










0 100 200 300 400 500 600 700 800Frame

0

2000

4000

6000

8000

10000O

bjec

ts







19 of 25


CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










CHAPTER 6






20 of 25






21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees














21 of 25


Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees










Bibliography

















22 of 25




















23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees




























23 of 25























24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees































24 of 25






25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees














25 of 25

Abstract

Acknowledgements

Introduction

Background

Rendering


GPU Rendering

Numeric formats

Document Formats



Quadtrees







