Extremely slow performance with specific file

[hybridherbst]

Describe the bug

A specific test file (for color space testing) is causing threejs to become unresponsive and take the entire browser with it.

To Reproduce

Steps to reproduce the behavior:

1. download the attached file
   unlit=color.zip
2. open the file in https://threejs.org/editor/
3. zoom out until you can see the content
4. note browser is hanging, changing tabs doesn't change that, have to kill browser

Expected behavior

File loads and displays fast, it's pretty small.

Screenshots
The file is a test case for textures/colors/vertex colors. It has many small meshes and materials but loads very fast in other systems (e.g. Babylon Sandbox or gltf.report)

Platform:

• Device: Desktop
• OS: Windows 10
• Browser: Chrome 95.0.4638.69

[Mugen87]

I can't reproduce this on macOS with Chrome 95.0.4638.69. Viewing the asset in the three.js editor and gltf-viewer works without performance issues.

On what systems/browser have you tested?

[Mugen87]

Here is a glitch with your asset for easier testing: https://glitch.com/edit/#!/nebula-lavish-ballcap?path=index.html

[hybridherbst]

Sorry, should have added - Windows 10, Chrome 95.0.4638.69. I also updated the original post.

I can verify that the same issue happens with the Glitch site, browser and machine immediately become unresponsive and the viewer never loads.

[Mugen87]

Okay, let me check the glitch on Windows later this day.

[Mugen87]

This is actually a duplicate of #22758 since your asset contains a lot of sRGB encoded RGB textures. The current workaround is to use WebGL1Renderer or by setting the minFilter property of all sRGB textures to THREE.LinearFilter (to disable the generation of mipmaps). I've applied this specific fix to the glitch.

[hybridherbst]

Thanks for verifying.
I believe in this case it's far worse than 10x though, it goes from "instant loading" to "never loading", is there another regression that goes from "constant shader compilation time" to "linear compilation time"?

[Mugen87]

With duplicate I just mean the problem is caused by the same issue. Let's continue the discussion in #22758.

[toji]

Something that's interesting to note with this file is that it only contains one texture, which is modestly sized at 1024x1024. (Could be smaller, since it's just solid color blocks, but whatever.) While I would expect it to have a small hitch as it generates the mipmap for that single file, I wouldn't anticipate anything like the freezing behavior that @hybridherbst is describing unless that same texture is being uploaded to the GPU separately for each of the 264 different materials that use the same texture. In which case... 😱

[Mugen87]

This assets exhibits a long-standing issue in the engine which we have tried to solve via #17949.

[WestLangley]

[toji]

Ah. Okay then. 😰

[hybridherbst]

@Mugen87 #22758 has been closed since #22759 has been merged and r134 is released.
Just for clarification, I assume this means that this case and type of files will stay problematic until #22846 makes it into a release?

[Mugen87]

Yes, r135 will not solve the texture uploading issue. This requires #22846 or a similar solution.

[mrdoob]

#22846 solved this.

Before	After