Suggestion: Caching texture buffers in WebGLRenderer

[AVGP]

I'm working on an application with many different code paths that load textures and I've patched the WebGLRenderer to cache textures also on the GL level, so that uploadTexture and onTextureDispose use a dictionary to see if a texture has aleady been uploaded or are no longer used, which can reduce VRAM usage and does not need sweeping changes in other parts of the code.

Is that a useful thing for others, too? Or is there side-effects I'm missing / is it too specific to be useful within three.js?

[mrdoob]

Hmmm, wouldn't it be better to implement that in WebGLRenderer itself?

[AVGP]

Oh, of course. I just wasn't sure if there might be effects I'm missing and that may screw people's day up. But I can't think of any - so would you be OK with a PR to implement this?

[mrdoob]

so would you be OK with a PR to implement this?

Yep! ^^

[titansoftime]

With this in play would caching textures in the app itself become redundant?

[AVGP]

Well, it would not prevent multiple XHRs concurrently trying to load the
texture but it would ensure that a texture is only loaded once into VRAM.
Am 08.12.2014 19:28 schrieb "Kevin" [email protected]:

With this in play would caching textures in the app itself become
redundant?

—
Reply to this email directly or view it on GitHub
#5728 (comment).

[titansoftime]

Ah gotchas.

[WestLangley]

@Mugen87 Can this be closed?

[Mugen87]

I think we should keep it open until its clear what will happen in context of THREE.Image. Duplicate texture uploads are still a problem in three.js.

[WestLangley]

@Mugen87 OK. Thank you for your input.

[WestLangley]

Duplicate texture uploads are still a problem in three.js.

So, let's fix it. This is a core issue and deserves to be addressed. What is the plan? Who has the skills to propose a solution?

[Mugen87]

What is the plan?

The original idea was 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. 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).

[Mugen87]

One prerequisite for THREE.Image is to decouple the actual texture upload from the parameter setting. Everything is currently triggered in uploadTexture() right now. However, when having THREE.Image and THREE.Texture, both operations needs to be done separately. That means some serious refactoring in WebGLTextures.

Related issue #14375

[WestLangley]

@Mugen87 Great answer! Thanks!

Rather than discussing all of that in this thread, can you open a new issue(s) as a feature request with the stated goals? Then we can assign (or request) someone to have a go at it.

[Mugen87]

There you go! #17766

[Mugen87]

Closing in favor of #17766.