traits for textures

[nowakf]

The various _Texture<'a> and _Target<'a> types:

1. have functionality in common (width(), etc).
2. have variants that all have functionality in common (generate_mip_maps, etc).

Do you think it would be worth it to define some kind of 'Texture' trait? The _Texture and _Target enums are nice, but they're borrowed, so if you want to have some struct that is generic over what kind of texture it holds, but owns that texture, you're out of luck.

[asny]

I definitely considered it (I think I actually implemented it as a trait at some point), but each time I add a trait, the code becomes a bit more complex. It is also a bit harder to follow the code, an enum is very easy to reason about. Also, all the texture types have common functionality, but they also have a lot of fundamental differences. Finally, enums perform better than traits, however, I'm unsure how much it matters in practice.

Can you give an example of a struct that would benefit from a texture/target trait? Could you use an enum instead of a generic struct? Maybe one that owns the actual texture/target and not just a reference to it. Note that it is cheap to generate a target every time it's needed, for example as_color_target on a Texture2D.

[nowakf]

So the motivating example is something like this:
pub struct ShaderScreen {
ctx: Context,
events: Receiver<()>,
paths: Vec,
shader: Program,
}
This basically watches a bunch of files, then recompiles the shader if they change - I'm using it to produce textures and shaders and see how they'll look in a scene. Right now I store a texture separately and pass it as a colortarget, then when I want the data, I read from that texture. I guess I felt it would be neat to have the texture owned by the ShaderScreen, because that's basically what we're operating on all the time, but it's not necessarily 2D - it might be a cubemap or whatever, so it would be something like:

pub struct ShaderScreen<T: Texture> {
ctx: Context,
tex: T,
events: Receiver<()>,
paths: Vec,
shader: Program,
}

Now I think about it though, perhaps an enum is necessary in any case: to allow for changing the texture type at runtime (although dyn exists I guess). The awkwardness is I'd be calling the same methods on every match arm (new_empty, width, height, as_color_target, etc).

Anyway, I very much appreciate your reluctance to add more traits - I live in fear of trait-generated error messages.

PS: I've been having a lot of fun and learning a great deal reading three-d's src, so many thanks for your work.