Replace elmesque with a conrod-specific layout tree?

[mitchmindtree]

@bvssvni has been doing some bench-marking and it led to some discussion about alternatives to elmesque's purely-functional allocation-heavy graphics layout approach.

Original discussion here.

This would be quite the breaking change, however there could be a number of benefits to this approach:

• The design would not be restricted to elmesque's aims to stay representative of the elm-lang graphics modules.
• We could remove the confusing distinction between the Form and Element types and consolidate them under one Form type for example.
• It could be easier for a Widget to re-use and update its existing graphics description/layout (elmesque doesn't provide a way to do this).
• It would be easier to provide a simple conrod backend API (Conrod should expose (or at least re-export) everything a user needs to use their own graphics and event backends. #576) as we could easily make the rendering of our custom system generic over our own backend (this might be trickier or not as nice using elmesque).
• One less dependency - slightly easier to maintain.

I can picture this being done as a "graphics layout tree", where rather than building the tree using boxed recursion, we provide a little tree data structure (a wrapper around something like rose_tree) to each widget which only gets allocated once and can be re-used every Widget::draw. The API could be very similar to as it is now, just with the tree being described in the data structure rather than the type recursion, removing the need for all the elmesque related allocations. We might even be able to do all widgets within a single tree - rather than providing each widget with it's own unique tree, we could provide a safe wrapper around the branch of the master tree that represents that widget's graphics layout.

[mitchmindtree]

After making a short start, I've realised that conrod already has all of the functionality necessary for layout described by the Position type and the edges of the widget graph.

If we can simply represent each of the graphics fundamentals as unique Widgets, we should be able to massively simplify conrod's drawing while significantly increasing performance by taking advantage of the widget graph cache.

This should remove the need for any kind of Form or Element type altogether.

I'll add a separate issue for this idea.

[masche842]

I was just about to open a new issue when I stumbled across this.
I like conrod's approach a lot and would like to adopt it in a project. However, as I'm working on embedded systems with very small display sizes (think 320x240), a set of vertices that have to be rendered is just overkill.

I've transcripted a small c-based gui library to rust (open sourced soon) and therefore have the primitives (Lines, Pixels, Fonts, etc) available, being directly written into a framebuffer device (or a piston_window base simulator for development).

When I tried to adopt conrod's widget system I found myself copy and pasting stuff around because the slim implementation is already there - but depending on piston2d-graphics and elmesque.
So, do you/ does anyone has an idea if it's possible or appropriate to abstract conrod even further, that is: getting rid of elmesque (answer is yes as can be seen above) and the tight coupling with the graphics crate?

Hope this is still suitable for this issue, I will create a new one otherwise. Meanwhile: Any comments and ideas are welcome!

[bvssvni]

@masche842 I picture either making Conrod backend agnostic over the graphics API, or we'll improve piston-graphics. You can now override the methods in the Graphics trait to do the rasterizing directly. See https://github.com/PistonDevelopers/graphics/blob/master/src/graphics.rs#L15-L138

[masche842]

@bvssvni Wow, exactly what I was looking for like a month or two ago. I will try to implement a custom graphics backend on top of my current framebuffer implementation and see if that will work in my case (in terms of performance i.e.). On the other hand I really like the idea to make conrod backend agnostic as this reduces dependencies and somehow allows pragmatic/lightweight solutions. Nonetheless it's surely quite a lot of work, I'm aware of that.