Improving performance of piston-graphics for Conrod

[bvssvni]

See @mitchmindtree's comment #830 (comment)

Related to #664, but this is a bit outdated.

• Make an example that pushes the limits so we can get profiling data
• Check that font rendering in Conrod uses piston-graphics optimally
• Optimize what we can in piston-graphics backends before making changes to the design

If draw calls are the bottleneck, then it is probably textured vertices, which can be batched in the backend when using the same texture. Gfx and Glium could collect chunks together and submit them when the buffer is full, just like with colored vertices.

[kvark]

Keep in mind that gfx/GL is not ready for profiling at this point (gfx-rs/gfx#978). We have a lot of missing caching logic in there (we had some caching, but it was scrapped when we transitioned to PSOs, and no new caching was done), including the low-hanging fruits, that would certainly lower the draw call cost.

If you want to profile piston-graphics, using the Glium backend might give you some better (more useful) results. cc @mitchmindtree

[tl8roy]

More of an observation rather than anything concrete, performance on systems with no GPU acceleration is poor.

I am trying to use conrod on an ARM processor. It doesn't look like the GPU is being used so performance is painful even with simple applications.

Is Glium likely to be better in this regard?

[mitchmindtree]

@tl8roy the glium feature is currently the significantly more performant option and will be until we can update the piston back-end to try out the new graphics_tree crate.

See #852 for a short description of the current difference in performance. The glutin_glium.rs example demonstrates how to use this feature.