Draw the remaining render::Primitives within the glutin_glium.rs example

[mitchmindtree]

In #734 conrod introduced a more flexible method of rendering in a "backend agnostic" manner. Instead of requiring a constrained graphics backend, conrod now simply renders the entire Ui as a list of render::Primitives.

#734 also introduced a glutin_glium.rs example in order to demonstrate this flexibility and demonstrate how to use conrod with glutin and glium directly. The PR correctly handles Text, however the other Primitives are not yet handled.

• Rectangle
• Lines
• Polygon
• Text
• Image Could probably take inspiration from the way Text is rendered.

[clicketyclack]

I did some experimentation in a seperate branch:28b0c79

I added some code to handle polygons, glutin_glium.rs#L158 but left the vertices-pushing code below at glutin_glium.rs#L245.

Do we want to convert Line primitives to triangles before sending into glium? Otherwise my conclusion is that we'll need some way of switching the GL draw mode (TriangleList, LineStrip) etc before sending in the vertexes for each conrod primitive. I see a few different approaches:

• Moving the glium calls on lines 245-253 to the end of the PrimitiveKind::Text block at glutin_glium.rs#L227, then implementing new glium calls in each of the match cases.
• Switching vertices to some sort of glium_queue vector where each item would be a GliumQueueEnum, such as a vector of vertices, a color change command, etc. This is the same approach as the Command enum in Unsure about how to deal with the primitive's scissor in a batched render backend #809.

Using TrianglesList vs LineStrip:

[clicketyclack]

@mitchmindtree Am I correct in assuming that the render loop from examples/glutin_glium.rs should be moved to src/backend/glium.rs later on?

[mitchmindtree]

Oh awesome! Thanks heaps for looking into this - exciting stuff :)

Switching vertices to some sort of glium_queue vector where each item would be a GliumQueueEnum, such as a vector of vertices, a color change command, etc. This is the same approach as the Command enum in #809.

I'm not experienced enough with GL to know which option would be the most efficient performance-wise, but I feel like this option is probably the cleanest in terms of API 👍 I like the idea of providing a pipe-like function in the glium backend which takes the render::Primitives as input and produces a list of glium-specific enum variants like you mention as output. This way we can still make it very easy for the user to draw the primitives while still giving them control over the actual drawing 👍

Am I correct in assuming that the render loop from examples/glutin_glium.rs should be moved to src/backend/glium.rs later on?

Yeah exactly 👍

[clicketyclack]

Guess I should post an update. It's turning into a monster.
glutin_glium.rs

Current appearance is below.

Few points:

• Polygons are filled now, but concave ones have issues. I.e. the fin "armpits" are unintentionally also filled.
• The colors are temporarily wacky because of debug purposes.
• There are 4 orientation triangles on each side, also for debug purposes.
• The top right widget is a widget::Image. I added my own texture because rust.png is black-on-transparent. Those two colors make trying to figure out GL shader coloring very confusing.
• A few widgets unintentionally use the glyphcache texture. I think it's interesting how it orders the glyphs by height. Also the cache is mostly blank.
• The top left widget is a widget::Circle. Seems to work.
• The fish polygon can not be moved or scaled.
• Under it is a widget::Toggle. There is no label support.
• Bottom right is a 200px wide, 50px high button. Obviously something wrong there.
• The canvas background is always square. Resizing the window shows the purple glium background.

[mitchmindtree]

Haha wow, this is looking like some kind of abstract early-net era artwork 💯 Awesome job on making it this far 👍

Perhaps it'd be a bit easier to make clearer progress on this if we have a "correct" version of the example to compare it to...

I've been thinking that we could re-do the all_widgets.rs example (so that it actually uses all widgets) and then use this as the GUI for both the glutin_glium.rs and glutin_gfx.rs examples. By this, I mean we add a module to the examples/ directory that contains a demo App type and a gui fn which could then be re-used in each of the examples. This way we can compare the one drawn with piston to the glutin_glium.rs and glutin_gfx.rs ones and ensure that the behaviour is correct over each of them. Also saves us from having to come up with new abstract widget artworks to test the glutin_glium.rs and glutin_gfx.rs examples 😉

I might have a look into this later today.

[clicketyclack]

Yup, very placeholder-ish for now. I can simplify the poly, perhaps a textured half-moon? Or something more asymmetrical? Btw, I think the fish is flipped. The two fins were on the bottom when I inkscape:ed it. Could be an export issue though.

We def. need a better test texture long-term too, showing off all R,G,B,A channels. The shader in trunk clobbers the G and B channels!

Would also like some lines in the all_widgets. I'm uncertain about how we want the line end caps should look.

I probably won't commit anything until the weekend.

[clicketyclack]

Weekly progress report...

Done:

• Merge in changes from WIP - Introduce new all_widgets.rs example that actually uses all widgets. Use this same gui between different backend examples for easier testing and comparison. #851 .
• Add texture/color mixer weight into shader, so we can set vertexes to color vs texture again.
• Fix various artefacting.
• Implement basic lines support in renderer.

Todo / bugs:

• Understand / convert glyphcache 1-channel texture vs RGBA.
• Why are the ball coords treated as outlines?
• Close polygons (i.e. indent in bottom left one)
• Why is the BG color different?
• Get better at handling more textures. Convert shader uniform to SrgbTexture2dArray?

Glium on left, examples/all_widgets on right.

[mitchmindtree]

Hey @clicketyclack, nice work 👍

I had a look at your code and attempted to clean it up a bit and re-write some parts to make it a little more efficient and address some of the bugs. Here's some screenshots of my progress (taken from my retina display):

Think I managed to address most of your points! The fork is here if you're interested.

I only have a couple steps left but I'll probably leave them for tomorrow:

• Work out why the rust logo isn't renderering.
• Triangulate line joins properly and handle line cap.
• Handle scizzor properly.

After I've done those, I'll move what I can into nice abstractions within the backend/glium.rs module and then do a PR 👍