mbernat / diagrams-opengl Goto Github PK

It's pretty easy to get diagrams-opengl to eat 16+GB of RAM, without managing to draw anything. Drawing an array of 400 circles, for example. I'm not sure whether there's an actual memory leak / loop, or if we're just being that inefficient in triangulating curves.

The manual has the following example:

ts = mconcat . take 3 . iterate (rotateBy (1/9)) $ eqTriangle 1
example = (ts ||| stroke ts ||| strokeT ts ||| fromVertices ts) # fc red

The expected behavior is that in the first diagram, each triangle conceals the edges of those below it. In the second, all lines are visible.

In the this backend, the second looks similar to the first---though the drawing order is reversed!

I'm pretty sure we can get the expected visual result by sorting the GlPrims in renderPath so all the lines are drawn after all the Triangles. I'm not sure if this actually reflects the semantics of <> on Trails, though; need to think about this more.

Was thinking about implementing text rendering using Freetype2 package.
( http://hackage.haskell.org/package/freetype2 ) I have a little experience working with it. What do you think?

Diagrams has switched from a flat list of primitives to a tree, with attributes and primitives held farther up the tree. The list version is going away soon, so -opengl needs to catch up.

[deepfire@andromedae diagrams-opengl]$ ghc-pkg list --user
[deepfire@andromedae diagrams-opengl]$ git head-ref
4d804b6
[deepfire@andromedae diagrams-opengl]$ cabal install --upgrade-dependencies
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: diagrams-opengl-1.0
rejecting: vinyl-0.3 (conflict: diagrams-opengl => vinyl>=0.2 && <0.3)
trying: vinyl-0.2.1
trying: transformers-0.4.1.0
rejecting: linear-1.10.1.1, 1.10.1, 1.10, 1.9.1, 1.9.0.1, 1.9, 1.8.1, 1.8, 1.7
(conflict: diagrams-opengl => linear>=1.3 && <1.7)
rejecting: linear-1.6, 1.4, 1.3.1.1, 1.3.1, 1.3 (conflict:
transformers==0.4.1.0, linear => transformers>=0.2 && <0.4)
rejecting: linear-1.2, 1.1.4, 1.1.2, 1.1.1, 1.0.1, 0.9.2, 0.9.1, 0.9, 0.8,
0.7, 0.6.1, 0.6, 0.5, 0.4.2.2, 0.4.2.1, 0.4.1, 0.2.0.2, 0.2 (conflict:
diagrams-opengl => linear>=1.3 && <1.7)

Replace hand-coded triangles with NURBS control points

Andrey says there are some cases where the current clipping doesn't do the right thing. I haven't tested enough to know where these are.

It would be nice to have an example of rendering a Diagram into a window within a Gtk or Qt application. I haven't used either toolkit enough to know what's necessary. Is the Result GLFW.Window -> IO () sufficient, or is the Window type too restrictive?

Projects that incorporate diagrams-opengl have to mimic the folder structure that contains the shaders used. Not doing so results in the error

Example: src/Graphics/Rendering/util.v.glsl: openBinaryFile: does not exist (No such file or directory)

It would be nice to be able to ship binaries of those projects without shipping the shaders with it and since the shaders are bare bones and not likely to be under constant development I think it would be okay to include them in src/Graphics/Util.hs similar to how I do it here. What do you think, @bergey ?

Hi,

It would be great to have some backend for GL.

Is there any chance that this could be made to work with the recent versions of all dependencies?

Thanks! (for reading :) )

See changes: diagrams/diagrams-lib@c816d60

Add install directions to read me, referring to other git branches

Add camera position and orientation to the render options. Set default to isometric