Three.js加载含10000×5500大纹理的GLTF模型时Chrome完全冻结如何解决

你遇到的15秒卡顿本质是超大尺寸非标准纹理的GPU上传阶段主线程阻塞，不属于JavaScript逻辑执行耗时，所以Chrome的JS性能分析器不会记录为可识别的运行任务，才会出现卡顿时间段空转的现象：

• 你使用的10000×5500像素纹理属于非2的幂次尺寸，WebGL渲染前会先做一次全量重采样适配，额外增加计算耗时
• 未做压缩的该尺寸RGBA纹理原始显存占用约为220MB，浏览器将纹理数据从内存拷贝到显存的操作默认是同步阻塞主线程的，该过程由浏览器内核和GPU驱动执行，不会暴露到JS调用栈中

1. 纹理预处理优化（优先级最高）

• 将纹理分辨率调整为符合WebGL规范的2的幂次尺寸，推荐改为8192×4096（和原始比例接近，不会出现明显拉伸），可以直接消除额外重采样的开销
• 转用压缩纹理格式，优先选用Basis Universal/KTX2格式，配合Three.js的KTX2Loader加载，压缩纹理的解码、上传流程都可以在Worker线程完成，完全不阻塞主线程，同时显存占用可以降低到原有的1/4~1/6
• 如果必须保留原始分辨率，可以将大纹理拆分为多张2048×2048的小纹理分片，逐块上传GPU，避免单次大内存拷贝操作长时间锁定主线程

2. 加载逻辑优化

• 无需mipmap的场景下，将纹理的generateMipmaps属性设置为false，关闭mipmap生成流程，减少纹理上传阶段的计算量
• Three.js r135及以上版本可以调用renderer.initTexture(texture, onReadyCallback)主动异步初始化纹理，等纹理上传完成后再将模型加入场景，避免阻塞渲染循环

• 打开Chrome的about:tracing工具，勾选gpu、renderer相关类别后录制加载过程，可以查看到GPU线程的纹理解码、上传全流程耗时，定位具体阻塞环节
• 开启Chrome DevTools的WebGL Inspector面板，同时打开Three.js调试模式WebGLRenderer.debug.checkShaderErrors = true，可以查看纹理上传的具体参数、状态和耗时
• 剥离模型逻辑，仅保留纹理加载逻辑写最小复现Demo，排除模型解析、材质初始化等其他环节的干扰

该现象不属于Chrome或Three.js的bug，是WebGL 1.0标准的原生设计限制：WebGL 1.0的纹理上传默认为同步操作，WebGL 2.0的异步纹理上传API目前还存在兼容性问题，优先通过上述优化方案即可解决问题，无需提交bug报告。

内容的提问来源于stack exchange，提问作者Antonio Noack