Closed mitchmindtree closed 7 years ago
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:
PrimitiveKind::Text
block at glutin_glium.rs#L227, then implementing new glium calls in each of the match cases.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.Using TrianglesList
vs LineStrip
:
@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?
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 :+1: 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 :+1:
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 :+1:
Guess I should post an update. It's turning into a monster. glutin_glium.rs
Current appearance is below.
Few points:
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.widget::Circle
. Seems to work.widget::Toggle
. There is no label support.Haha wow, this is looking like some kind of abstract early-net era artwork 💯 Awesome job on making it this far :+1:
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.
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.
Weekly progress report...
Done:
Todo / bugs:
SrgbTexture2dArray
?Glium on left, examples/all_widgets
on right.
Hey @clicketyclack, nice work :+1:
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:
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 👍
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 ofrender::Primitive
s.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 handlesText
, however the otherPrimitive
s are not yet handled.Rectangle
Lines
Polygon
Text
Image
Could probably take inspiration from the wayText
is rendered.