WebGL Performance Regression in Chrome? Older Demos Run Significantly Better on Firefox

Questions
1

Hi All

To keep it short, I recently noticed some strange lags on a new Babylon.js project running in Chrome.

When I test the exact same scene on Firefox, everything is perfectly smooth — great performance.

I couldn’t find any issues in my code that would explain this discrepancy (I really hope it’s not my code!).

To check if the issue was local, I decided to test an old, quite GPU-intensive online project. The results are striking: Firefox performs much better than Chrome. Firefox is smooth, while Chrome is very choppy.

Could you please test the provided URL on your end? I’m hoping it’s just a local issue on ‘my end’ and that Chrome and Firefox behave the same way for everyone else.

My specs are: Windows, latest versions of Chrome and Firefox, NVIDIA RTX 3060.

Edit/Update: I just recompiled the project from the URL above locally using Babylon.js 8.4. Firefox is still significantly ahead in terms of performance. (60 fps vs 40-50fps in chrome)

URL to test: https://trk-360.com/demo/index.html (v7.11.2)

(Please note: there is no preload screen, so you may have to wait 20-30 seconds for the scene to load completely.)

Thanks for your feedback and help! But maybe it’s just the ‘Friday Night Bug’? :upside_down_face:

2

Is it the same with older Babylon version ? (just to be sure it is browser only) and were you able to try with an older Chrome version ?

3

Oh I just noticed the v7.11.2 part :frowning: so definitely on their side of the house.

Would you mind opening a Chromium bug with the info ? and share it here ? I ll pass it along ASAP to our colleagues on the browser side.

4

Just to be sure, firefox is better on your side ?

5

Yes, when did you notice the regression ?

6

This would help bissecting the Browser changes to figure out what could cause it

7

Also as a quick test, after the instanciation of the engine, could you try setting disableUniformBuffers to true ? and the second experiment setting engine.getCaps().supportSRGBBuffers = false ?

Those were two perf culprits in the past and I wonder if the fixes could have regressed somehow.

8

also can you think of a playground I could use to repro locally ?

Sorry again for all the questions, just trying to get it sorted as fast as possible.

9

Cannot confirm? Chrome fast, Firefox slow. (There is no fps indicator, but Firefox is visibly creepingly slow. Chrome has the occasional lag (LOD switch?) but runs smooth otherwise)

10

I only noticed the regression yesterday. It had been a long time since I last ran the demo.

Setting disableUniformBuffers to true and/or checking engine.getCaps().supportSRGBBuffers as false made no difference.

I posted the demo back in June 2024. I just reinstalled Chrome version 126 from June 2024. The demo now runs normally/smoothly, with no more lag. I will try on my end to find when the specific Chrome version that reproduces the ‘malfunction’ . I will also check the graphics drivers. Thanks for your help !

11

thanks @Joe_Kerr for your feedback !

12

Version 140.0.7339.207 (Build officiel) (64 bits) run the demo smooth too.

13

I reproduce the problem in Chrome retail 142.0.7444.177 (Official Build) (64-bit), but it’s ok in latest Chrome Canary 145.0.7564.1 (Official Build) canary-dcheck (64-bit).

14

I use Chrome for Testing: téléchargements fiables pour l'automatisation des navigateurs  |  Blog  |  Chrome for Developers to get the older version. I didn’t know that tool before.

The weird thing, if I used the latest version with ChromeTesting no lag, the officiel version on my pc lag.

testing
testing978×438 22.2 KB

Maybe we should wait a bit now and see if the inconsistencies persist in the next update. Nothing is really coherent.

15

Woah, look at this. I wanted to try one last thing and switched to my Nvidia GPU. Major FPS drop with unresponsive browser.

16

Good idea ! I enable in my bios the intel iGpu, and it runs smooth !
You found the culprit :grinning_face:

17

I’ve just downloaded Version 145.0.7565.0 (Build officiel) canary (64 bits), and sadly I reproduced the problem on my nvidia GPU.

1 Like
18

I guess a Chromium ticket with those info would be amazing at this point ? and I ll be sure to forward ASAP as it sounds pretty bad even more if not totally addressed in Canary.

1 Like
19

Found ! I just isolated the problem, it is now running at 60 fps. I will share a playground and details soon.

1 Like
20

The mistake was located in the GPX track path drawing. It is drawn onto a large dynamic texture and then blended within each shader of every tile.

The error or inconsistency I noticed is that, within the updatePath method, I was not starting the path with the beginPath instruction. I was continuing directly my lineTo instruction with every call.

In the playground that illustrates my laggy development environment, simply uncommenting lines 48 and 49 restores the normal behavior.

Playground Link: https://playground.babylonjs.com/#EQ3271#2
Fixed Demo Link: https://trk-360.com/demo1/index.html

Is the new Chrome version more strict? Were the older is more permissive? regression on their end ? Or is it simply a development error in my code that took advantage of a lax environment?!

up to you to determine the appropriate action now.

Strangely, firefox is completely stuck with the playground, the demo runs smooth…