1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

CRITICAL

* use in SoleScion

OPTIONAL

+ silently ignore svg it can't handle, rather than barfing
+ linear color gradients
* render elliptical arcs by polygonising them
* expose elliptical arcs as circular collision boundaries
+ override calculated anchor with a point from the svg
+ opacity
* consider making automatic anchor a centroid rather than just the center
* consider animation - store multiple frames in a single svg file?

PERFORMANCE

* we can merge some of the vertices that come out of tessellation.
  (try a concave quad to debug this)
* asking the glu tessellation for edge flags should force it to return just
  GL_TRIANGLES, presumably simplifying and speeding up our tesselation code.
* consider reclaiming memory by forgetting paths that are triangulated, and
  forgetting triangles that are used in a batch. (or maybe not storing them in
  the first place - make the operations more functional?)

NOT PLANNED

* bezier arcs probably not going to happen - I just don't care.
* radial gradients probably not going to happen, since as far as I can see,
  they are going to end up looking kinda wonky in OpenGL unless you add a bunch
  of extra vertices to smooth them out.
* Line paths and other svg entities, like rectangles, are probably not going
  to happen. I don't see the utility - I might as well just draw everything
  as polygons.

DONE

+ construct an GL_TRIANGLES batch using indexed vertices from hard-coded params
+ parse coords of a single triangle from svg (one-red-triangle.svg demo)
+ parse fill color from svg file
* invert y coords (svg y axis points down, ours points up)
* path coord lists can be comma or space separated
+ multiple loops per path (three-orange-triangles.svg demo)
+ tesselate loops with more than three vertices (green-star.svg)
+ nested loops that form holes and islands (green-star-with-hole.svg works!)
* merge the multiple GL_TRI primitives returned by tessellate() into a single
  primitive. NO! Don't. This is already done for us by Batch.
* we must preserve the ordering of paths so that they get added to the batch
  (and drawn) in the right order.
* new class, SvgBatch, which maintains an list of paths
* unfilled paths should not be tessellated
* untessellated paths should not be added to the batch
+ calculate an anchor point, offset all paths so anchor is at origin
* SvgLoader should expose aggregate attributes like width, height.
* Batch could be a property of svgloader
+ expose named paths by id, for eg. collision detection
+ upload to PyPI
+ tests (and my copy of 'mock') are now included in sdist