Introducing THREE.Image

Moved the discussion from #5728 to a separate issue.

The idea is to add THREE.Image as an additional class which is used by THREE.Texture. An instance of THREE.Image is directly mapped to an instance of WebGLTexture (the raw WebGL texture object). That means multiple textures can refer to the same instance of THREE.Image and not causing redundant texture uploads anymore (related issues #5728, #5821, #7223)

Ideally, THREE.Image will make the handling of image objects transparent (e.g. the difference in HTMLImageElement, ImageBitmap or the image stub in DataTexture is encapsulated in this new class).

[donmccurdy]

What would be the goals of this change? From the issues attached I see two:

1. Ability to use different values of repeat and offset on the same texture, without duplicate GPU upload. Using multiple THREE.Texture instances would not duplicate data as long as the underlying THREE.Image was reused.
2. Prevent UniformsUtils.clone() from causing duplicate GPU upload. Cloning THREE.Texture instances would not duplicate data as long as the underlying THREE.Image was not cloned.

For (1), adding THREE.Image sounds like a good solution under the current API. Depending on how/if/when we are introducing NodeMaterial, there may be others:

material1.color = new TextureNode( texture, uvNode1 );
material2.color = new TextureNode( texture, uvNode2 );

For (2), I’m not sure whether UniformsUtils really needs to clone textures, or could just copy by reference.

I don’t have an opinion for or against this change yet, just trying to understand the goal and whether the additional abstraction is the right solution.

[mrdoob]

THREE.Image ended up being named THREE.Source #22846