The application is experiencing long freezes when switching fractal types for the first time in a session.
The problem is spited into 2 questions:
-Main Problem: Long initial loading times for each fractal type, even with high end pc’s, across all browser types.
The core unresolved issue is the 35-50 second (can be longer on slower hardware) loading time that occurs during the createShader() and shader() calls when a new, uncached fractal shader program is compiled for the first time. i have identified that after the initial loading time, you can safely use f5 or even restart your pc. and the loading time will be almost instant since all the data is somehow saved in the shader cache.. So the only problem is, why does the initial loading time has to be so long? I am almost 100% positive that this isn’t just the fact the shader code it long. and that it’s related to some badly optimized behavior of the code. it doesn’t make sense that it will take 50 secs to load with 4090 GPU and a new I9 CPU.
How to check for yourself? open the code for the first time, it will take a long time to load. if you are using any chromium based browser expect a freeze until the loading is finished. do not close the browser during this period. after the loading was done you can choose new fractal types. it’s thte first option in the ui menu. once you switch to a new fractal type, you see the browser will freeze again and load for about 50 secs. depends on your hardware. then you can safely f5 and try again and you will see all the shaders you already loaded will now load almost instantly..
I already tried: Directly modified the const int MAX_RAYMARCH_STEPS (to 30) and const int MAX_DE_ITERATIONS (to 3) values within commonFragParts_GLSL. Outcome: While the visuals degraded significantly (confirming the shader used the new low constants), the first-time compilation freeze duration in Chromium remained at ~50 seconds. This indicated that unrolling these specific main loops was not the primary driver of the extreme compilation time.
The most compelling explanation for the Windows-specific delay is Chrome/Edge’s use of ANGLE (Almost Native Graphics Layer Engine) .
On Windows, ANGLE translates GLSL ES shader code to HLSL for Direct3D.
For very large and complex GLSL shaders (like the user’s, which are ~36KB and feature many uniforms, conditional compilation for dual numbers, and multiple DE functions being swapped), this GLSL-to-HLSL translation can cause the source code to explode in size . A “normal” GLSL raymarcher can become megabytes of HLSL.
Metal Backend: On macOS, Chrome’s ANGLE path likely translates GLSL to Metal Shading Language (MSL), or Safari might use a more direct GLSL-to-MSL conversion. The Metal compiler is significantly faster and more efficient with large, branchy shaders.
Unified Memory (Apple Silicon): This architecture dramatically reduces CPU-GPU communication overhead, which would also make any necessary program introspection steps (like getProgramParameter) much cheaper.
All this info isn’t 100% certain, they are all assumptions i made.
Even if this info is true, i am still looking for a way to fix loading times and freezes.
-Secondary Problem: Dealing with browser freezes in chromium based browsers
Only in browsers like, Edge, Chrome, Brave etc.. not only that there’s a long (Around 50 sec loading time) but also the browser itself freezes. but when i use firefox. the loading time is there. but the browser will not freeze. is there a way to somehow make sure it won’t freeze on chromium based browsers the same way it doesn’t freeze on firefox?
I’m on a Mac, and for what it’s worth, the load time isn’t super long for me, maybe just a second or two, both on Chrome and Firefox. Have you tried using your browser’s profiler to see what’s taking up the time? Here’s the result for me, loading your sketch:
None of this takes super long, but there are two big blocks. One of which is in the shader creation, and it is calling getProgramParameter a number of times to get all the uniforms in the shader. Back-and-forth between CPU and GPU is often the bottleneck, but less so on Macs with Apple silicon, so that may be why this is running OK for me but not you. It looks like your shaders have a lot of uniforms, so this slow call happens a lot of times on shader load. To confirm if that’s the main slowdown, maybe you could try temporarily turning some uniforms into hardcoded constants to see if that speeds things up? The other block I see is creating a bunch of sliders. You could also try commenting out the code that builds the UI for now to see if that is more of a bottleneck than the shader.
For the freezing, the first step is probably also to determine the cause. If you see JavaScript code taking a long time, that could help indicate what spot needs to be worked on. If you use your browser’s profiler and you don’t see much happening in JavaScript, then often that means it’s the GPU that’s running slowly, and in that case maybe it’s the shader that’s taking a long time to run. A possible optimization could be to only clear the screen and redraw when a UI parameter changes.
Very interesting. i tried on a few Windows based pc’s and the loading time is massive even with high end hardware. something about the fact you are using mac must be causing this and yeah ill try using the browser tools to dig in deeper to what might cause this.
Also just to verify we are on the same page, are you sure the “second or two” loading time is the initial loading time? the very first time you open the app and switch between fractal types it only takes a second or two? it must mean that something about mac fixes this but i don’t know why.
I ran it on a mac m2 with Safari browser and experienced no problems that I can see. It loaded quickly and everything appears to work as expected. It’s a very impressive piece of work in my opinion.
Ty, as it seems the problem is specific to WIN operating systems only.
On mac it works.
If you have the possibility to check with windows ill appreciate it.
and btw i’m glad you liked it, it’s only in early access most of the actual features i have planned aren’t even implemented yet
Yep! So this is in the weeds, but I think some integrated GPU systems share memory between the CPU and GPU parts of the chip, and can do some fancy stuff like dynamically change what is used where or have fast CPU/GPU transfers. I’m far from an expert in this hardware stuff but it sounds like that’s what recent Apple silicon macs do? There’s also a chance that if your Windows setup has an integrated graphics card in addition to a high end graphics card, if the bottleneck is on data transfer rather than computation, the integrated graphics might be faster despite being less powerful. Anyway, trying to use less uniforms to see if that speeds things up could confirm this theory.
Tried your app on Windows 11 with Firefox browser; was unable to run it. Spent all my time looking at spinning circle and finally got a freeze message:
Yes you see now?
That’s the problem, the reason you spent so much time and eventually got error is because the compilation took too long… on my hardware which is probably stronger it takes 50 secs to load and it doesn’t crash. but it’s already known to me that it does crash on weaker systems that are Windows based.
My question is, you have any idea how can i fix this ?
i wish there was a way to make the code work perfectly like it does on MAC
If you have any idea or if you can try to check for the source of the problem
anything that could spill some light on this matter, id be glad.
Thanks in advanced!
