Add support for binding textures directly from a TextureSequence

[PathogenDavid]

Fixes #1645

[PathogenDavid]

Something I realized while applying pattern matching to the other path is that these two paths handle getting the texture ID at different times. (My path reads it in the shader.Update function, the other one reads it in the Observable.Defer and captures it for the closure passed to shader.Update.)

Not entirely sure if that has any observable behavior differences. My gut says that my implementation is probably slightly better since consumers of Texture probably shouldn't make assumptions about the ID since they don't own it, but let me know if you want me to make them match either direction.

[glopesdev]

My path reads it in the shader.Update function, the other one reads it in the Observable.Defer and captures it for the closure passed to shader.Update

This can be an important point, the main difference is that the timing of the code outside the closure can be controlled by the input sequence, whereas running code inside the closure we cannot make any assumptions about when exactly it will be run. This can be important when Index is changed dynamically just before the call is made, e.g. using InputMapping. Sometimes we do this to emulate batch execution of render pipelines.

Because of this detail, if anything I would tend to err on the side of capturing outside the closure. The easiest way to do this would be to change the signature of the delegate to receive the captured nullable, e.g.:

        IObservable<TSource> Process<TSource>(IObservable<TSource> source, Action<int?, TSource> update)

[PathogenDavid]

Because of this detail, if anything I would tend to err on the side of capturing outside the closure. The easiest way to do this would be to change the signature of the delegate to receive the captured nullable, e.g.:

That's sensible. Looking at it closer though, I ended up refactoring the function to take a getter for the texture ID instead of an update function.

Your suggestion would've only unified the capture of Index, but the actual texture ID was still different.

It's a bit more of a change, but I think it better matches the existing behavior exactly in both cases.

[PathogenDavid]

Revisiting this again with a fresh mind, I realized we were both getting a little caught up on the update delegate approach of the previous implementation.

The latest iteration does away with the delegate entirely and instead has Process<TSourcce> handle the input being a texture when the texture name isn't specified.

This technically makes the Process(IObservable<Texture>) overload redundant, but I kept it so that it's still documented separately since I felt like that probably makes more sense from a user perspective. (Can remove and revise the documentation if you feel it's unnecessary though.)

The diff looks like I changed documentation but I actually just moved the body of the private Process(IObservable, Action) into the body of Process<TSource> since the helper is no longer useful after removing the Action.

As an aside, is it desirable that we just nothing when there's no texture? Seems like it should maybe be an error.

[glopesdev]

Sorry for the confusion in my previous comment, it took me a while to fully reload the context of this operator and while doing several edits to the comment I probably failed to explain myself correctly.

I think this will be the last iteration and happy to go back to having everything in one method. This is basically the same as your previous proposal except introducing an extra local instead of renaming the cache variable.

Indeed this operator is surprisingly nuanced, and I learned several things from this review so definitely worthwhile!