Experimenting with generics for backend type passthrough

[bhperry]

This is an alternative implementation to #76
And more importantly, an experiment in a different way to handle pixel's interactions with backends.

While working on the pixel Actions PR, it began to feel a bit like a hat on a hat on a hat as input arrays are passed up through the stack (OpenGL -> GLFW -> Pixel), copying at each level and creating more garbage to be collected. So I started experimenting with generics to see if I could get around that.

The idea is to store inputs in the backend's native type, and then when the user checks an input win.Pressed(pixel.MouseButton1) we do the mapping from pixel -> backend type instead of the other way around.

[bhperry]

And a pixel code base would not be able to easily switch between backends, so that's a deal breaker. But ditching the generics this gives me an idea for a better way to handle it while still mapping to pixel types.

[dusk125]

And a pixel code base would not be able to easily switch between backends, so that's a deal breaker. But ditching the generics this gives me an idea for a better way to handle it while still mapping to pixel types.

Haven't been following along, but if you mean it should be able to switch after startup, we can ignore this. Once a user selects a backend, they're stuck with it unless they tear everything down and start again.

[bhperry]

No didn't mean after startup, just that I think it's not a good design pattern for the project that you wouldn't be able to switch over to a different backend with relative ease.

[dusk125]

Makes sense!

[bhperry]

Ok ignoring the stuff I said about the end-user referencing backend types directly, this could actually work. Store inputs as the backend native type, and then do the type mapping in the other direction at query time. WDYT?

[bhperry]

causes more problems than it solves