Complete glium.rs backend and update glutin_glium.rs example accordingly.

[mitchmindtree]

The glium backend feature is now complete! Big thanks to @clicketyclack for kicking this off :)

The implementation uses a single shader program to render the entire GUI. For GUIs consisting of purely text and shapes, the entire GUI will be drawn with a single draw call. Otherwise a new unique draw call will be required for each new image and scizzor that appears, however we might be able to improve this using a TextureArray or mapping to a single texture in the future if necessary.

After updating the glutin_glium.rs example, I did some profiling and found the changes to be a significant improvement over the all_widgets.rs example (the same gui but rendered via piston_window).

The all_widgets.rs example (piston_window backend) idles at ~6.5% CPU, draws 60 frames of text at about ~60% CPU and at about ~65% CPU when scrolling.

On the other hand, the glutin_glium.rs example idles at about 1% CPU (though I anticipate this to drop further once we configure the gui to only update upon new input events). When using ui.draw instead of ui.draw_if_changed (and in turn uploading to the GPU roughly 60 times per second) the example peaks about about 7% - a very promising sign for heavily animated GUIs like timelines, etc. When scrolling continuously over large blocks of text it peaked at around 20%, though the vast majority of this time was spent in rusttype's glyph cache.

Here are some pics!

Room for improvement

• haven't had a chance to do line joins/caps yet, but that should be easy to add.
• might be able to improve performance slightly again by using an index buffer. By doing this, we'd probably be able to cut back on about a third of the vertices uploaded via the vertex buffer.
• use a TextureArray (or one big large texture) for uploading multiple images to the GPU at once, allowing to cut down on draw calls.

Closes #752.

[mitchmindtree]

Travis' failure is due to some breakage upstream when compiling gfx with nightly. Going to merge!

[mitchmindtree]

@Boscop did you say you were using glium? If so you might be interested in this.

[Boscop]

Thanks @mitchmindtree, great work!
Does this mean it's possible draw a HUD GUI over a glium-rendered scene now?

[mitchmindtree]

@Boscop Yep!

[Boscop]

Ok, great. If I want to draw my glium widgets in a certain rect area that will be spared out by conrod rendering, what's the best way to calculate the rect pos / size to align the areas?
Or can I even use conrod's layouting for this?

[mitchmindtree]

rect area that will be spared out by conrod rendering

Hmmm not 100% sure what you mean by this?

[Boscop]

I mean I want to render some of my GUI in conrod, and some of it in glium with shaders, so I draw the glium stuff first, and then conrod over it, but how can I prevent conrod from drawing its background over what I drew underneath?

[Boscop]

@mitchmindtree For example, let's say I want to render my midi view with glium because it has so many rectangles for the notes and I want to batch draw them in a shader. But I want to draw the rest of the GUI with conrod so that I can have sliders and dropdown menus etc.
So I have to know the rect area where the midi view should be, so I can render it there, and tell conrod not to draw anything there, not even background. How should I do this?