I think that the system wide slowdown is due to paging by the gpu driver which downloads pages from vram to ram and then to swap. For some uses that's ok (stopped redrawing because in background or not redrawing often). Most uses of webgl will not work when the driver starts to page.
On desktops what you'd actually like to know is how much vram you can consume before DOSing the system. On ARM systems with a unified ram (and no swapfile) you're sharing the ram with JS and everything else. The amount available to you can change without you allocating WebGL objects. The exact size of consumed vram is not actually known because you can't query how much ram FBOs, Shaders, etc. actually consume.
So if introducing such an API the following things should be addressed:
- How to query the available vram
- How to query how much objects you allocate use up
- How to query how much vram you used in total
- How to notify your application of changes in available vram
The reason that this should be addressed is because if you can't query it the following things will happen:
- DOSing peoples machines
- Triggering context loss, and an attempt to restore resources upon context restore will lead to another context loss, ping pong forever.