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.

[asny]

I definitely see your point and I think it's a very valid idea to make the ShaderScreen generic over the Texture. I've been exploring that pattern a lot, also when developing three-d, and in my experience, it complicates things immensely. If you did that, then when defining the ShaderScreen struct, you'd either had to specify the texture type or add the generic parameter to the parent struct as well. Quite fast, it cascades and suddenly you'd find yourself having to define generics all over your codebase. That's my experience at least. So that is why I'm only using traits in two cases:

• In a library where the type should be extendable from outside of the library (example: using three-d, it should be possible to create your own type of Geometry and still use the rest of the functionality)
• Data storage where the generic type is very primitive (example: a texture generic over the primitive data type, ie. u8, f32 etc.)

I'm not even sure the second use case is really necessary, but it works ok since you know the primitive data type on construction.
This also means that if you're doing an application and not a library, you don't need traits, just use enums. You might have to write a few more lines of code, calling the same function on every match arm, but it makes everything much much simpler.

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

Ha, yeah, true, that is also a downside of traits 🙂

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.

That's really nice to hear, thank you. Glad it's useful, also as a learning material 🙂