Hi All,
I have a very basic scene with 3 objects and I remarked that the threejs loads very slowly, it is strange for a really basic scene.
I used Chrome “Performance” tab, and i see that the “getProgramInfoLog” takes a lot of time, it is the only function who makes the website slow. Any idea what is it and how can i improve it?
Um, normally getProgramInfoLog() is executed way faster. Do you see a difference when using Firefox or Safari?
Besides, consider to test with a different computer. This might be a device specific issue.
I too am having occasional hiccups (100 ms) with getProgramInfoLog … it’s a startup thing. Happens very consistently and only with getProgramInfoLog. Trying to resolve it now =(
just comment it out. it is only there to get shader errors for console output.
also renderer.getContext().getProgramInfoLog= function() { return '' } might work.
It would be great if affected users could report this issue to browser vendors. There is maybe a way to address this issue in the WebGL implementation somehow.
Thank you for the hint and direction… I’ve been afflicted with startup hiccuping for, well, years. Currently working with rev 141 in electron-v21.1.1-win32-x64
After eliminating getProgramInfoLog per your suggestion another hiccup remained (seemingly in its place)… at getProgramParameter.
After poking around a bit it seems WebGLRenderer.compile() was insufficient to eliminate shader compile delay (in theory you do ‘compile’ of everything at start then don’t have the user seeing the delays). If you replace the getProgram calls within that function with setProgram instead then these problems go away.
Below is screenshot of compile delay long after startup, but using the original ‘compile’. You can see fast frames before and after this slow frame… I rotated camera so new object comes into view. This went away with the change shown below. Hopefully this is complete and correct, as I’ve been wildly slinging code for hours… just now I double checked by undoing my fix(hack).
Wow. I saw this thread by chance when bored.
For fun I set renderer.debug.checkShaderErrors = false; My app now loads 2x fast.
That was a luck find lol! Here I was blaming my own app!
From the documentation:
If it is true, defines whether material shader programs are checked for errors during compilation and linkage process. It may be useful to disable this check in production for performance gain. It is strongly recommended to keep these checks enabled during development. If the shader does not compile and link - it will not work and associated material will not render.
Thanks, I’ll take my chances for the insane performance increase lol
My players will let me know if something bugs out. Thanks!!!
Hi,
The shader compile/link operations are carried out asynchronously to your Javascript in a separate GPU thread./process (even without parallel compile implemented), so those calls appear to complete quickly. (for Chrome at least).
However when you make any WebGL call that needs to see the result of the compile/link operations, that call waits for them to complete. For obvious reasons, getProgramLogInfo() is one of those calls, and hence the delay you see is not the time taken to get the log, but is mostly the time waiting for the compile/link to complete. The same applies to the getProgramParameter() call, eg getting gl.LINK_STATUS
Hi, I just tested it but not helped in my case…
Its may be work fast in “render.compile()”,
not in “function render(){ animate(); renderer.render(scene,camera) ... }”
No changes into my scene.
In case it helps someone else, as I stumbled into this thread while investigating this problem:
@aardgoose already explained it perfectly but I would like to insist to give it more visibility. If the GPU is busy no matter what the ‘native’ WebGL call is then it will show in the chrome dev tools performance profiler as the operation taking the long time. It’s not that this specific operation (getProgramInfoLog) takes a lot of time but that when it’s called the GPU was already maxed-out doing something else and any new sync operation involving it will be delayed until it finishes.
That’s why when removing the getProgramInfoLog call then the getProgramParameter appears as the new long operation, it just took over because the GPU can’t handle the load.
