Don't upload texture if locked using TEXTURELOCK_READ

[liamdon]

The API docs suggest that you can call texture.lock() with a mode of either TEXTURELOCK_READ or TEXTURELOCK_WRITE, but in this option doesn't do anything.

This is a small change so that a lock that's opened with TEXTURELOCK_READ will not call texture.upload() when unlocked. It also uses the mode to check the state, instead of overloading texture._lockedLevel for this purpose.

I also have some related questions about how we should handle mip updates via API - please see #6004

[erikdubbelboer]

You can completely remove _lockedLevel as it's unused after your changes.

[liamdon]

You can completely remove _lockedLevel as it's unused after your changes.

Definitely - but I think it could still be put to good use as described in #6004, so depending on what the PC team thinks about that, I may add more to this PR.

[slimbuck]

TBH the team had internally mumbled wanting to completely rewrite the texture API, but this is often a pipe-dream. Breaking backwards compatibility is very painful for us and our users.

I love this PR and the issue you created with explanation. It is well thought out and a clear improvement to the API - thanks so much!

[mvaligursky]

related to #4237

[liamdon]

related to #4237

Ha, I actually forgot about this! I guess this API has been on my mind for a while 😄

[willeastcott]

Nice PR - approving (although agree with the feedback from @mvaligursky)

[mvaligursky]

Nice, thanks!

[liamdon]

I'll probably follow up (soon-ish) with a PR that implements my proposal in #6004; it may be easier to consider/discuss when you see a concrete implementation.