Is it? Web browsers aren't that much slower than native (around 2x with web assembly and WebGL I think).

It's much harder for apps that are trying to render to the DOM (which is very slow). But WebGL apps should be perfectly fast in browsers...

All WebGL implementations have significant overhead compared to native GL. For example, just clearing the screen at 60 fps taxes my CPU at 10% on Windows (30% on Linux) while a C program that does the same uses 0% CPU.

The reason for the performance penalty with Firefox on Linux is that the framebuffer content is copied from GPU to host memory, compositing is done and then it's copied back to GPU.

For other platforms I'm not sure.

Further, SIMD support has been removed from Javascript and not been added back to WebAssembly yet, so that's another factor 4-8 for computation-heavy code. Experimental pthread support is only available in Chrome experimental for now due to the Spectre and Meltdown exploits. And general GPU compute apparently is really tricky to implement in a secure way, although DOOM does not use it.

> copied from GPU to host memory, compositing is done and then it's copied back to GPU

Shouldn't happen with GPU compositing in Firefox (layers.acceleration.force-enabled), right?

It has been years that we have WebGL running in the browser, not to mention Linux kernel ect ...

Hardware acceleration in Linux? someone pinch me, I'm dreaming.

I'm talking about running Linux in the browser:

https://bellard.org/jslinux/