Moved gl_device out

[kvark]

Closes #80
Depends on https://github.com/gfx-rs/gfx_device_gl/pull/1

The biggest problem is security. Once device_gl is in a separate crate, it can no longer construct Handle and *Mapping types, since they have private fields. Making the fields public could be a temporary solution but I wish we had something more secure to offer.

[brendanzab]

Maybe they could be unsafe getters/setters?

[brendanzab]

I will think on this.

[kvark]

@bjz I think I know a good solution:

• Add a DeviceInternal trait, implement create_handle and create_mapping_* in it (default implementation that doesn't need to be overwritten)
• Auto-implement it for everything that implements Device
• Don't re-export it in gfx root, but it's still accessible via gfx::device::DeviceInternal

It's unlikely that anyone will try to reach for it, but even one does - one probably knows what one is doing. There is gonna be near zero chance of "accidental" creation of invalid handles and such.

[kvark]

Note to self: cleanup instancing parameters in the renderer.

[kvark]

Ok, the last problem now is with macros. Having a code like this doesn't really compile:

impl<R: gfx::Resources> gfx::VertexFormat for Foo {
   type Resources = R;
   ...
}

Because Rust doesn't know how to constrain R:

the type parameter R is not constrained by the impl trait, self type, or predicates [E0207]

Any ideas?

[kvark]

Here is a standalone snippet exposing the problem:

trait Foo {}
trait Bar {
    type F: Foo;
    fn fun(&self, Self::F);
}
impl<F: Foo> Bar for () {
    type F = F;
    fn fun(&self, _:F) {}
}

One straightforward solution would be to provide an exact Resources type to the macros: #[shader_param(gfx_device_gl::Resources)]

However, I don't like where this is going. Not only it is already verbose, even if you do a typedef, it would be the hell in a complex application with many vertex/shader formats and multiple supported backends. Too much noise, especially since it's not obvious why the original one shouldn't work.

@cmr halp

[kvark]

@Kimundi provided a good explanation on why this is not sound:

I don't think this can be made to work, since you'd have many possible associated items for the same type ()

The solution, as it seems, could be to remove the associated type from VertexFormat, making R a generic parameter.

[kvark]

@bjz @csherratt - this is ready

I fought with ShaderParam a lot, ending up just with a parameter as proposed earlier. It's gonna take us a while to reach the limitations of this model.

[kvark]

Also, deferred example doesn't work for me. When rendering to Gbuffer, we get an exception saying the target frame doesn't have depth (mask = 64). I tried logging it up in the example code, and the mask seems to be 71, so something happens inside the submission. I blame that Rust bug.

[ghost]

yay~

[ghost]

LGTM. I'd like @bjz to look over it too.

[kvark]

@csherratt sure thing. Thanks!

[brendanzab]

This is ok for now, but it would be nice to have a better way.

[kvark]

Right, I just wasn't able to come up with anything better than that... The problem comes from the fact that this structure has to implement ShaderParam for every device. We need to somehow make it device-independent.