WebGL Can Be Moved Off The Main Thread With Latest Firefox

[phoronix]

Phoronix: WebGL Can Be Moved Off The Main Thread With Latest Firefox

With Firefox 44 and newer it will be possible to move the WebGL rendering work off the main processing thread...

http://www.phoronix.com/scan.php?page=news_item&px=WebGL-FF-Off-Main

[Michael_S]

I keep thinking core Firefox is doomed to just limp along while Servo becomes the future of Mozilla, but they keep adding and fixing things in core Firefox one bit at a time. I wonder whether Servo will be Firefox main in 2020. Maybe not.

[zanny]

I keep thinking core Firefox is doomed to just limp along while Servo becomes the future of Mozilla, but they keep adding and fixing things in core Firefox one bit at a time. I wonder whether Servo will be Firefox main in 2020. Maybe not.

It absolutely will, that is the whole point of Rust + Servo. Once its reached feature and performance parity with Gecko they are going to replace them in a continuous upgrade of Firefox.

Gecko as a rendering engine might die, but Servo is good because it implements the Chromium Embedded Framework API and thus is literally a drop in replacement for any application using it.

[abral]

It absolutely will, that is the whole point of Rust + Servo. Once its reached feature and performance parity with Gecko they are going to replace them in a continuous upgrade of Firefox.

They've already replaced some (pretty small) Firefox modules with Servo modules, e.g. an audio metadata parser.

[Michael_S]

It absolutely will, that is the whole point of Rust + Servo. Once its reached feature and performance parity with Gecko they are going to replace them in a continuous upgrade of Firefox.

Gecko as a rendering engine might die, but Servo is good because it implements the Chromium Embedded Framework API and thus is literally a drop in replacement for any application using it.

Right. But that very seriously means that a lot of the current work going into Gecko is throwaway - they're patching up something they plan to discard in a few years. I understand the need, Servo isn't ready and Gecko as-is lags WebKit in some ways. But it's a tough position to be in as a company (edit: foundation, not company) and for their developers.

I also wonder if the counterpart to Servo should be a rewrite of SpiderMonkey. My understanding - which mostly comes from these forums and could be flawed - is that SpiderMonkey has one instance across all browser tabs while V8 has one instance per tab, and the result is that on one tab vs. one tab benchmarks between Chrome (or Chromium) and Firefox the SpiderMonkey engine holds it own and often wins but for real world use scenarios with many open tabs Chrome is faster. Can they fix SpiderMonkey, or does it also need a ground-up rewrite?

[smitty3268]

Right. But that very seriously means that a lot of the current work going into Gecko is throwaway - they're patching up something they plan to discard in a few years. I understand the need, Servo isn't ready and Gecko as-is lags WebKit in some ways. But it's a tough position to be in as a company (edit: foundation, not company) and for their developers.

I also wonder if the counterpart to Servo should be a rewrite of SpiderMonkey. My understanding - which mostly comes from these forums and could be flawed - is that SpiderMonkey has one instance across all browser tabs while V8 has one instance per tab, and the result is that on one tab vs. one tab benchmarks between Chrome (or Chromium) and Firefox the SpiderMonkey engine holds it own and often wins but for real world use scenarios with many open tabs Chrome is faster. Can they fix SpiderMonkey, or does it also need a ground-up rewrite?

That doesn't have much to do with Spidermonkey, the JS engine. It's higher level than that - they need to change the higher levels in the browser to create a new thread to run each tab, the JS engine bits should just fall out of that naturally. They've already got a project to do that, it's just a big project and going to take a while. Also, I'm skeptical that it will really change much in terms of benchmarks - where Firefox does well in anyway - it's more about latency and odd freezes/pauses at poor times while you are trying to do things.

[Michael_S]

That doesn't have much to do with Spidermonkey, the JS engine. It's higher level than that - they need to change the higher levels in the browser to create a new thread to run each tab, the JS engine bits should just fall out of that naturally. They've already got a project to do that, it's just a big project and going to take a while. Also, I'm skeptical that it will really change much in terms of benchmarks - where Firefox does well in anyway - it's more about latency and odd freezes/pauses at poor times while you are trying to do things.

My suspicion - which is mostly a wild guess - is that the odd freezes and pauses at poor times is related to the global Javascript instance instead of the per-thread instance. Obviously without extensive use of a profiler I could be totally wrong.

[smitty3268]

My suspicion - which is mostly a wild guess - is that the odd freezes and pauses at poor times is related to the global Javascript instance instead of the per-thread instance. Obviously without extensive use of a profiler I could be totally wrong.

Right - I think it's a combination of JS garbage collection and other C++ resources that are being locked by one tab that ends up hitting you while you're in another. The entire UI is rendered by 1 thread currently, so if that thread ends up reading in files from disk it will end up blocking all drawing in the browser until it's finished. I know a while back they spent some time trying to convert all those over to async IO, but i'm sure there's more left and anything it does that takes a while can easily lock the browser up.

But the fix isn't going to happen inside the JS engine. It's going to be changing tabs to use separate engines.

The project to split everything up is called Electrolysis, by the way. It's been around for a long time, and they put it on hold for a while, but AFAIK it's currently planned to be released sometime this year and there are people working on it.

[Michael_S]

Right - I think it's a combination of JS garbage collection and other C++ resources that are being locked by one tab that ends up hitting you while you're in another. The entire UI is rendered by 1 thread currently, so if that thread ends up reading in files from disk it will end up blocking all drawing in the browser until it's finished. I know a while back they spent some time trying to convert all those over to async IO, but i'm sure there's more left and anything it does that takes a while can easily lock the browser up.

But the fix isn't going to happen inside the JS engine. It's going to be changing tabs to use separate engines.

The project to split everything up is called Electrolysis, by the way. It's been around for a long time, and they put it on hold for a while, but AFAIK it's currently planned to be released sometime this year and there are people working on it.

I realize my response is late, sorry. I have the Firefox nightly with Electrolysis running, and it's generally a help but so far not a full performance fix.