Significant Performance Dif between Chrome and FF

Is this a normal difference? Identical scenes but 72fps (Chrome) vs 16fps(Firefox). Edge’s FPS are very similar (74) to Chrome, so FF is the odd one out. Obviously, FF is Gecko on PC not a Webkit like Edge or Chrome, but still that is a massive difference. Is this what other projects are seeing?

The performance difference has been going on for a while, I figured I would shake it all out down the road when I got around to optimizing and taking care of bugs. But, things got really bad after I started added in a 2D GUI Layer (dropping 3fps (chrome) and 20fps (ff) with about 30 GUI controls) last night. So, I figured I would ask to see if any known performance issues / fixes have been noted between browsers.

Both scenes are identical builds of my project, using latest stable FF and Chrome on 4.2 release of engine. The only difference I can see is the browser. I did not know if there was a known issue with such performance differences between browsers.

I’m hacking away at this trying to hit a basic feature complete, so things are very much un-optimized and will be for weeks. It is too complex to playground. However, with that level of performance difference, it is making any sort of development verification difficult.

Your Firefox almost looks like it has no hardware acceleration enabled
Can you check ?

1 Like

Good thought. It was off. Odd, as I thought that Modzilla had that default enabled since V81.

After forcing it on and restarting no real difference. Then I did a computer restart, still no major improvement- maybe +5fps to 20fps for FF but that could have just been the reboot as Chrome is now running 90-120 fps after reboot.

This is also happening on my android (not really a target device until I move things to AR in a few months, but rules out a local FF issue), a Samsung S9. 33fps vs 4fps

Firefox for Android (4fps)

Chrome for Android(33fps)

Maybe SpectorJS can give you more insight?

Have you tried to remove everything 2D related? There may be a difference between how Chrome and Firefox handle canvas internally.

With all 2D HTML/CSS overlay disabled FF is still around 17-20fps while Chrome plucks along at 60+

Disabling all internal 2D BabylonGUI (GUI Layer) improved performance by 20fps in FF to around 41, Chrome as comparison is 60fps with same settings of absolutely no GUI. So, better but still a 20fps difference - which you can feel while moving around, and now I have no GUI :stuck_out_tongue:

I don’t know why deactivated (visible=false) internal 2D babylonGUI elements would reduce performance by 20fps and only in FF, but I need to get performance up to move forward. Is visible=false not actually deactivating them as fully as some other method? Since it looks like pure HTML does not cause any lag, I may experiment and try doing a 3d to 2d point call + cam distance to track a point and physically move DIV’s. I have sort of outgrown capabilities of babylons ui system anyway.

Back to my original issue, and just because no one else has reported this, I would assume the lag to be my code. However, I still find it strange there is that much difference between the two browsers. Any other thoughts or suggestions are appreciated.

isVisible=false only skip the drawing of the control in the canvas context, but the canvas itself is still copied to the GPU texture before the quad corresponding to the 2D GUI is drawn on the screen (and this operation could be slow, we currently have a perf problem with Chrome and WebGPU about that). If you want to avoid this copy, you need to disable the GUI altogether: you can either not create the ADT at all or simply set the layerMask of the underlying layer of the ADT to 0 (adt.layer.layerMask = 0).

Regarding your perf problem in FF, I think you should monitor the timings of the function calls of a frame/range of frames and compare between both browsers (there’s the Performance tab in Chrome and I assume something similar does exist for FF).

1 Like