Abstract shapes & render performance

[rehno-lindeque]

The recent discussion on #118 by @jazmit got me thinking...

Shape currently means "polygon" in Elm (a list of points). I would like to propose that it would make sense to move towards an abstract representation to shapes that makes a distinction between BasicForm, Shape and Polygon.

The invariant that qualifies something to be a Shape would be the function...

type alias LevelOfDetail = Float
tesselate : LevelOfDetail -> Shape -> Polygon

...so that something like Text is excluded.

There are a couple of nice attractions:

• Renderer abstraction: Every renderer is different. One concrete example is rendering a Circle to SVG: it will be much cleaner if the algebraic representation is preserved. One could even render shapes relatively cleanly to Html using stylesheets. There's also a chance render quality could be improved - for example, it might make sense for a renderer to implement specialized anti-aliasing for curves and circles.
• Renderer performance: There could be large performance benefits to specializing rendering. There's a good chance that canvas.arc is orders of magnitude faster than a highly tessellated polygon. It's also quite likely that arc uses an adaptive tessellation that could take any number of interesting things into account to improve quality and performance. Another example would be a WebGL renderer, rendering circles and curves with shaders.
• Memory use: would plummet :). Just 1000 circles * 50 points * 2 coords * 8 bytes = 800 000 bytes.
• Algorithms: Any algorithm that works with polygons would continue to work with shapes since it can always be converted to a Polygon. The advantages are also many since it allows for more specialized CSG, ray tracers/view cones, physics etc.

Much of the above probably requires Shape constructors to be exposed, which I think might be a tad premature. Never-the-less, performance might be something worth looking into sooner. Myself and @TheunisKotze are about to do some testing to see what effect this has on us - we draw a helluvalot of circles. I'll report back!

[shmookey]

Renderer abstraction would be super handy. I'd really like to be able to write a function toSVG : Form -> SVG, so it would be great if BasicForm(..) and ShapeStyle(..) were exposed.

[shmookey]

Renderer abstraction would be super handy. I'd really like to be able to write a function toSVG : Form -> SVG, so it would be great if BasicForm(..) and ShapeStyle(..) were exposed.

[evancz]

Sorry this did not get attention til now! The Graphics.* modules now live in evancz/elm-graphics so I am trying to get stuff migrated over there.

Not sure what action to take here, but I expect to be focusing on <canvas> for professional users and "friendly graphics" for learning as separate use cases. Progress will be made when those start happening.

[evancz]

Sorry this did not get attention til now! The Graphics.* modules now live in evancz/elm-graphics so I am trying to get stuff migrated over there.

Not sure what action to take here, but I expect to be focusing on <canvas> for professional users and "friendly graphics" for learning as separate use cases. Progress will be made when those start happening.