lighter getProgramCacheKey when using RawShaderMaterials (#22650)
* lighter getProgramCacheKey when using RawShaderMaterials
The gist of the problem: each new material instance gets run through this getProgramCacheKey function to see if three needs to build a program for that, or to connect a reference to an existing program.
The getProgramCacheKey function is ‘ok’ for built in shaders, but it has a pretty huge allocation for custom shaders, by way of making the key out of concatenating the full strings of the fragment/vertex shaders.
This wasn’t too much of an issue as long as the materials can be set up front, as it was a one time cost during load, but I'm noticing that with 3d-tiles based streaming, our current method of creating unique ShaderMaterial per tile, each new tile shown is a pretty large memory allocation, and for larger tilesets, where it’s possible to view thousands of tiles over time, this adds up to a healthy amount of GC pressure.
* lighter getProgramCacheKey when using RawShaderMaterials
The gist of the problem: each new material instance gets run through this getProgramCacheKey function to see if three needs to build a program for that, or to connect a reference to an existing program.
The getProgramCacheKey function is ‘ok’ for built in shaders, but it has a pretty huge allocation for custom shaders, by way of making the key out of concatenating the full strings of the fragment/vertex shaders.
This wasn’t too much of an issue as long as the materials can be set up front, as it was a one time cost during load, but I'm noticing that with 3d-tiles based streaming, our current method of creating unique ShaderMaterial per tile, each new tile shown is a pretty large memory allocation, and for larger tilesets, where it’s possible to view thousands of tiles over time, this adds up to a healthy amount of GC pressure.
* lighter getProgramCacheKey when using RawShaderMaterials
The gist of the problem: each new material instance gets run through this getProgramCacheKey function to see if three needs to build a program for that, or to connect a reference to an existing program.
The getProgramCacheKey function is ‘ok’ for built in shaders, but it has a pretty huge allocation for custom shaders, by way of making the key out of concatenating the full strings of the fragment/vertex shaders.
This wasn’t too much of an issue as long as the materials can be set up front, as it was a one time cost during load, but I'm noticing that with 3d-tiles based streaming, our current method of creating unique ShaderMaterial per tile, each new tile shown is a pretty large memory allocation, and for larger tilesets, where it’s possible to view thousands of tiles over time, this adds up to a healthy amount of GC pressure.
Co-authored-by: Dave Buchhofer <[email protected]>
Dave Buchhofer