About FBO and getProgramInfoLog delay.

[state303]

Hi everyone!
First of all, thank you all for this great framework. Been enjoying it ever since I found.

I have a simple question regarding the FBO and the 3.5 second long delay; which happens due to the 'getProgramInfoLog' process.

On Debian environment, the loading is significantly lower (like 200ms)

Packages

pkg	version
Next	15.1.4
React	19.0.0
@react-three/fiber	9.0.0-rc.4
@react-three/drei	https://pkg.csb.dev/pmndrs/drei/commit/d2d25601/@react-three/drei

Notes

Not using Next turbo thing, just a plain Web Pack setup (followed next-three-drei template)

Example (takes some time.. like 5 seconds..)

https://codesandbox.io/p/devbox/l49qhm

Is there any possible solution to asynchronously build the texture, such that UI doesn't get blocked?
Will write some detailed post on the solution over this problem, but it seems the block cannot be avoided in this scenario.

I tried suspend, dynamic import, etc, but none works without initial freeze on the browser's end, due to the WebGL being blocked with getProgramInfoLog.

Found some old issues that mentions disabling it with getContext().getProgramInfoLog=() => ''; , however, it won't help on this case.
Should I utilize web-worker in this case? or... is there any good references I could dig in?

Edit

There was a duplicate post on here.
And it seems to be related to the KHR_parallel_shader_compile support but closed on asyncCompile implementation PR.

[CodyJasonBennett]

gl.getProgramInfoLog comes from shader compilation, which is blocking as program linking and validation waits on shaders to compile. This is done serially in three.js, so all (unique permutations of) materials will compile in lockstep. Same story with any other GPU resource, like (geometry) vertex buffers or textures which are uploaded from the CPU. WebGLRenderer.compileAsync would help in the case of many meshes or unique programs, but not in the case of a single material or blocking resource. Precompiling shaders or preloading textures helps when there is already parallel work to begin with, but strictly introduces latency otherwise. Further, compressed texture formats like KTX2 or image bitmaps would help with textures and move image decoding off of the main thread.

The linked example is a problematic one since it's pulling in quite a complicated noise function. The second or 3D noise function is simply Perlin noise (which Curl noise extends). My suggestion would be to precompute the noise patterns in a texture and look it up (AKA LUT or Look Up Table). This should speed up the shader quite a bit and incidentally lower compile time. Unfortunately, Codesandbox is easily broken here for me so I can't download or modify your example without the site crashing.

[state303]

My suggestion would be to precompute the noise patterns in a texture and look it up (AKA LUT or Look Up Table). This should speed up the shader quite a bit and incidentally lower compile time.

Thank you for super detailed answer! Sorry for the codesandbox, it must've been eye-soar to bear the spaghetti..
I think your answer pretty much covered all my question and above. Again, thank you very much!!

I will mark as answer and hopefully bring some how-to for other newcomers about this.
Have a nice day!