Possibly enclose `draw()` arguments into a struct about gfx HOT 13 CLOSED

(I'm Rainfly_X)

It might not shave out as many parameters, but we might consider not putting all the arguments into struct fields, for example, renderer. Any mutable global-ish state might do better as non-struct arguments to the draw call.

Not sure yet how that would complicate a more unified, enum-based calling system, given that different calls may have different "mut-global" parameters.

from gfx.

@campadrenalin to be fair, renderer is the only mutable parameter there, and it's passed as &mut self for all the call types:

pub fn draw<'a, L, T: shade::ShaderParam<L>>(&'a mut self, mesh: &mesh::Mesh, slice: mesh::Slice, frame: target::Frame, bundle: &shade::ShaderBundle<L, T>, state: state::DrawState) -> Result<(), DrawError<'a>>

from gfx.

Well, that's not so bad, then. Sounds like the main concern, then, would be boxing the values?

from gfx.

@campadrenalin With the new draw list architecture in place, is this issue still relevant?

from gfx.

@kvark I've been out of the loop for awhile, and I was only just barely in it in the first place. Could you point me toward some documentation and/or examples of the new draw list architecture?

from gfx.

@campadrenalin see reddit, our bug #203 and PR #209. For the usage, look into gfx-rs examples. The triangle one re-uses the same list each frame. The cube re-fills the list:

// resetting the list and filling it up, possibly on a separate thread
list.reset();
list.clear(
    gfx::ClearData {
        color: Some(gfx::Color([0.3, 0.3, 0.3, 1.0])),
        depth: Some(1.0),
        stencil: None,
    },
    &frame
);
m_model.x.x = 1.0;
data.u_ModelViewProj = m_viewproj.mul_m(&m_model).into_fixed();
list.draw(&mesh, slice, &frame, (&prog, &data), &state).unwrap();
// here is where it's executed
device.submit(list.as_slice());

from gfx.

As far as I can tell, this fulfills every high-level criteria that made a Draw struct seem attractive, including the hypothetical use case of a Drawable.GetDrawList() method. A+, guys!

from gfx.

Awesome, thanks! Let us know if you stumble into any issues.

from gfx.

Believe it or not, we've got the batch structures now: #282

from gfx.

Crazy coincidence... I'd just pulled this up via reddit, and was looking it
over when I noticed the email notification. Cool stuff! At least as far as
I understand it :)

On Wed, Aug 27, 2014 at 7:22 AM, kvark [email protected] wrote:

Believe it or not, we've got the batch structures now: #282
#282

—
Reply to this email directly or view it on GitHub
#143 (comment).

from gfx.

@campadrenalin sorry that it took almost a month for us to get there

from gfx.

No worries - I'm actually impressed at the pace gfx-rs updates. Maybe if I
was using it for anything directly, I'd be more impatient. But from where
I'm standing, you guys are really crushing it.

On Wed, Aug 27, 2014 at 8:50 AM, kvark [email protected] wrote:

@campadrenalin https://github.com/campadrenalin sorry that it took
almost a month for us to get there

—
Reply to this email directly or view it on GitHub
#143 (comment).

from gfx.

Haha, awesome. I hope we'll be in shape by the time you need us ;)

from gfx.