gl::Texture::update() should handle resizes internally

[richardeakin]

Currently you'll get a gl error if you try to call update() with data of different dimensions. The rationale behind handling this internally is that if you're performance savvy then you'll be using the same size image for a specific Texture, but it is basically free for us make it 'just work', as in calls glTexSubImage* if the data size is the same, or glTexImage* (basically re-init), otherwise.

[paulhoux]

See also the discussion in this thread:
https://forum.libcinder.org/#Topic/23286000002506003

[Gazoo101]

Given my recent interactions and previous experience, I'd lean towards update() using assert to check dimensions and format, but not automatically handle re-sizing. I'd think that's more 'surprising' as a developer, especially if you're not paying attention.

[richardeakin]

How are you 'surprised' when an image changes size? Personally I think assertions slow down development (since they usually crash the app) and should only be used when there really is an unrecoverable state. Trying to update() a gl Texture with an image that is a different size than it was constructed with is clearly not unrecoverable.

Principles aside, there are practical benefits to update() handling resize internally, one of which is that it simplifies async loading, where you might init the texture with a 1x1 placeholder (and return a valid gl::Texture2d), but then later fill it with the actual Texture.

On the other hand, I'd say that the Texture::Format has to remain consistent, as this simplifies the implementation and even usage to some extent.

[Gazoo101]

I'd say the surprise comes from the fact that the data changes as result of an assignment, which I perceive the update() function to be. Similar situations in my mind would be primitive data types in C++ which arguably do change the data upon assignment. But a primitive data type is a wholly different creature to me, compared to a texture which obscures the underlying differences.

You can't easily spot the difference between two textures just by looking at the definition, as you would be able to with, for example, a char and an integer.

I agree assertions do slow things down, so maybe a warning would be better suited?

I'm not certain I'm sold on only using assertions in unrecoverable situations though. There's a lot a system can do to recover, but it's more a question of where is the line drawn. How much should it do on its own to recover?

Finally, can't async loading currently also just be solved by replacing a 1x1 texture placeholder?