Define scope and philosophy

[brendanzab]

What should gfx-rs handle?

What should gfx-rs defer to the client, or higher level libraries/frameworks/engines?

[emberian]

The separation between device and render seems a bit hodge-podge, just shoving things into where they need to go. Additionally, what we have today can't work if we want to have a bindless backend, without introducing a lot of inefficiency. I think we should have a structure like the following:

trait Renderer {
    fn iter_errors(&mut self) -> ...;
    fn should_finish(&self) -> bool;
    fn clear(&mut self, Frame, ClearData);
    fn draw(&mut self, ...);
    fn create_program(&mut self, ...);
    /* ... */
}

struct BindlessDevice<Backend> {
    ...;
}

impl<B: BindlessBackend> Renderer for BindlessDevice<B> {
    ...;
}

struct BindingDevice<Backend> {
    ...;
}

impl<B: BindingBackend> Renderer for BindingDevice<B> {
    ...;
}

// BindingBackend would look a lot like todays `Renderer` struct, with the `device` crate etc, I
// think

I think all of the usual types can live in render (which could actually be merged entirely with gfx in this design, making render not exist). Then, each backend would implement the respective trait (BindingBackend/BindlessBackend), which would have associated types, avoiding the mess we have today where some types are in render or some types in device, depending on if the device needs them or not.

I think we can continue with today's design, though. My suggestion would be mostly a small code shuffling.

[kvark]

@cmr I can see how this is going to work. Do you think it requires associated types, or we can start putting this in slowly even now?

[emberian]

To have multiple implementations of the trait or to split it fully into
separate crates we will need associated types. With only one backend like
today it would be fine I think.

On Mon, Jul 21, 2014 at 6:42 AM, ----- notifications@github.com
wrote:

@cmr https://github.com/cmr I can see how this is going to work. Do you
think it requires associated types, or we can start putting this in slowly
even now?

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

http://octayn.net/

[emberian]

I think what we have today is good, both in terms of scope and implementation. Still some changes to make, such as my sketch above, but they are completely transparent I think.

[brendanzab]

@aturon Any idea on the time-frame for associated types? This is a big pain point for us :(

[brendanzab]

How about:

Goals

gfx-rs aims to be:

• a type-safe, memory-safe, and thread-safe API that encourages best practices
• blind to the actual semantics of the information it is recieving
• the default API for Rust graphics: for one-off applications, or higher level libraries or engines

Non-goals

gfx-rs will not handle:

• visibility determination
• draw call reordering
• de-serializing of scene data formats
• lighting and shadows
• abstractions for platform-specific shaders
• material abstractions

[kvark]

@bjz thanks, this is a great addition. Please file a PR that changes our README according to these notes (or adds goals.md with them that is referred from README), and we can close this.

[aturon]

@bjz I'm currently working on a design for associated items, which will turn into an RFC soon. It's not clear whether this will make it for 1.0, but I'd like to try!

[kvark]

I think this is resolved.