Different graphics driver being used in Firefox compared to Edge/Chrome

My machine is a Core i7-8700 with an NVidia GTX 1050 Ti. I’ve got a scene that runs pretty well in Chrome and Edge (Chromium 93), but the performance tanks in Firefox 91. According to the scene inspector, we’re using babylon.js 4.2.

Looking at the scene inspector, I can see that between the two browser engines, the graphics driver is different, and in turn, there is one feature that isn’t being used in Firefox. In Chromium, the listed driver is in line with what I have, ANGLE (NVIDIA, NVIDIA GeForce GTX 1050 Ti Direct3D11 vs_5_0 ps_5_0, D3D11- But in Firefox, the listed driver is ANGLE (NVIDIA GeForce GTX 980 Direct3D11 vs_5_0 ps_5_0) and parallel shader compilation is disabled.

I’m not certain if this is the root or just a symptom of my performance issues, but what might cause this?

Note that I’m in an enterprise environment and the advanced configuration pages in my browsers are locked out; trying to access about:config in Firefox gives me a message saying that the administrator has blocked access to the page.

There is unfortunately nothing we can do from our side :frowning: you should open a ticket on the mozilla bug tracker to ensure they would use the most powerfull card as we are by default requesting high-performance context.


When I saw this, it brought to mind how my Firefox is different from Chrome. I have the same graphics card. about:support, shows that I am getting the 1050 renderer for webGL 1 & 2.

I was really hoping that they were not using the same, but chrome://gpu shows they are :frowning_face:

I am using a Core i5 & am very up to date with OS. If you need any screen shots of stuff you are blocked from, feel free to ask.

As this topic is kind of out of frame works hands, permit to describe how the 2 browsers differ in my case. Colors on chrome all have some crappy green / blue tinge. Everything looks dead by comparison. Here is an old scene of mine https://palmer-jc.github.io/scenes/QueuedInterpolation/automaton/index.html

On firefox the flesh for the first model looks like:

While on chrome, they are:

It somehow looks even worse using PBR. Can someone run that scene on both browsers and check that this is not just my system, by alt-tabbing between them? Please.

Might be coming from sRGB not working on FF in some cases. @Evgeni_Popov do you remember the flag to disable sRGB altogether so @JCPalmer could try ?

1 Like

I think it was a setting somewhere from ICC color correction in Firefox - Mozilla | MDN

It seems it is this one in fact:


I did not get changing that to do anything.

My next test is even more basic. I viewed the texture file for the skin right in the github repo, Palmer-JC.github.io/young_lightskinned_male_diffuse2.jpg at master · Palmer-JC/Palmer-JC.github.io · GitHub

I get very different colors, similar to the scenes. I un-installed Chrome

In case it helps, that issue is not there on a mac. Skin looks the exact same colors in both browsers.

1 Like

Thanks @br-matt. I did re-install it, but nothing changed, so I left my message as it was, so no one would invest any more effort beyond what you did.

I use(d) chrome for:

  • Profiling
  • Remote console for my Quest 2
  • canvas.toDataURL('image/webp', quality) based video production

A webp image format (produced only on chrome) is equivalent to a single frame of an VP8 / webm container video. So I absolutely need the colors on MY system to be right, and being stuck on Chrome was a mistake.

Fortunately, I needed to also merge an audio track being generated at the same time as a separate file. webm container files are extremely complicated, so I wrote to the console a command line script to run for a program called ffmpeg to do it for me. I can also then change to mp4 and optimize for streaming at the same time.

Right at the end of a 3 week dev process in '18, I noticed ffmpeg also supported a raw video input option. It was too late at the time, so I stuck with webm and all this complex code.

Yesterday morning that all started to change. I switched to gl.readPixels to get my frames. Strung them all together (well new Blob did it for me) and wrote that out. I trashed a TON of code no longer needed!

I changed to generating a script to something like:

ffmpeg -f rawvideo -pix_fmt rgb24 -framerate 24 -video_size 3840x2160 -i "testing".raw -i "testing".ogg -vcodec libx264 -acodec aac -b:v 12000k -minrate 6000k -maxrate 17400k -bufsize 8700k  "testing".mp4

I have not run this yet, because on Firefox I got this warning:

WebGL warning: readPixels: Format and type RGB/UNSIGNED_BYTE incompatible with this RGBA8 attachment. This framebuffer requires either RGBA/UNSIGNED_BYTE or getParameter(IMPLEMENTATION_COLOR_READ_FORMAT/_TYPE) RGBA/UNSIGNED_BYTE.

Does this mean my data is probably garbage?

yup it usually comes from an incompatibility your readPixels function need RGBA in input not RGB I guess :slight_smile:

Good to know. My code is the same as the Engine cover for readPixels (that’s where I stole it from) except:

  • no promise. Sync is much easier for me. I control animation clock to get precise frames.
  • No format arguments.

Tomorrow I will look into why this context is RGBA and can that be changed. Can always do a first 3 only copy as a fallback.

1 Like

Turns out that if one of your textures has alpha (the eye brows in my test) you are just going to have to alpha from ReadPixels. Interestingly, Chrome & Edge also error, but their error msg is related to insufficient size. I just gave it a bigger buffer & asked for RGBA, then copied 3 of every 4 into the final Uint8Array.

I am testing with my dialog developer scene, which has a record functionality to be able to compare both mouth animation & voice generated as I make changes. This is a screen shot of the canvas part (a bunch of dom level form elements not shown). I am using a skin with a lot of make up, so cheeks / lips / under eye are supposed to look that way:

My script ran after file generation, but I got an all black video :frowning_face:. There is another program that comes with ffmpeg called ffplay, which can take the same rawvideo args. I ran it and it was almost working!!

Fortunately, Uint8Array has a reverse()` method, but I neglected also reverse the elements of my 3 of 4 transfer before calling it, so I got interesting result:

There is a forum for ffmpeg (I also have a 3 year old version), so think I will be able get videos which look good. @t3hp0larbear , thank for the use of your thread, welcome to the forum.