5 ms·

Parallel page rendering with Mozilla Servo

101 points by vezzy-fnord 11y ago

anonbanker 11y ago
This, along with the recent missteps Mozilla have been making (proprietary software included in the package, Cisco's h264 renderer, etc), remind me a lot of the Mozilla SeaMonkey days, when people were tired of bloat, and decided to give gecko a newer lighter body to live in. I'm hoping someone steps up to write a new lightweight servo frontend in rust.
slimsag 11y ago
> the team hopes to have an alpha release before the end of 2015. "I wouldn't recommend logging in to your bank with it," he said, "but it should be usable as a basic browser." What? Was this meant as a joke in relation to something else? -- Why shouldn't you log into banking sites with it?
- thomasfoster96 11y ago
  An alpha release of a new browser engine is likely to have quite a few security bugs. Don't risk your bank account details for the sake of testing a new browser engine.
  - slimsag 11y ago
    Fair point. Not trying to minimize what you're saying -- But I am genuinely curious as to how you'd test such a vast code-base written by so many different people for security issue? e.g. how will 1.0 be any more secure than alpha aside from developers having more time to "run into" the security issues by sheer luck/accident? Maybe someone vet the code by hand -- or maybe they will use a security testing suite to automate it? If so, wouldn't it make sense to do that before accepting code that could potentially introduce security bugs?
    - toyg 11y ago
      > how you'd test such a vast code-base written by so many different people for security issue? I think their point is that correct, well-thought-out and well-tested code (i.e. doing exactly what it needs to do, without side effects and errors) will inherently be more secure than any hacked-together it-runs-ship-it MVP/alpha/demo release (which is what Servo is, at the moment). Security-specific tests would be done in the same way as they're done for any mainstream engine out there.
- larsberg 11y ago
  The comment was meant to be lighthearted, but on the serious side we both: 1) Probably won't have done the full sort of inspection of our SSL cert checking to really ensure you aren't being MITM'd. 2) We won't have a chemspill / 0-day security fix infrastructure in place, so we won't have a way to push down fixes to 0-day exploits in OpenSSL, the JS engine, etc. I'd love to be at a better point on those features by the end of this year, but it's not likely with our current roadmap & resourcing plan.
falcolas 11y ago
I have to admit, I'm surprised they have no plans to migrate Firefox over to Servo. It seems like a waste, considering that desktops and laptops could both benefit from the increase in parallelism.
- logn 11y ago
  The way I read it, they have no plans in 2015/2016. Longer-term, we plan to incrementally replace components in Gecko with ones written in Rust and shared with Servo. We are still evaluating plans to ship Servo as a standalone product, and are focusing on the mobile and embedded spaces rather than a full desktop browser experience in the next two years. https://github.com/servo/servo/wiki/Roadmap https://github.com/servo/servo/wiki/Roadmap
- sp332 11y ago
  Multi-threaded rendering is less of a win when a single desktop core is already pretty powerful. Servo is going to make a big difference on mobile platforms with multiple underpowered cores.
  - pcwalton 11y ago
    That's not true. Layout is still often slow (multi-hundred ms) on desktop. You can notice that. Also powerful x86 CPUs are so good at shared-memory multithreading (cache coherency, large caches) that x86 is actually the best case for us (which is not to say we're bad on ARM, of course).
    - ksec 11y ago
      multi-hundred ms is slow.... But what is strange to me we have to go through a magnitude of handles and paralleling a browser engine to get to sub 100ms layout. Could we not further improve the current engine?
  - petecox 11y ago
    A 3 Ghz P4 from 2005 way well blitz a Core-M from 2015 on certain single-threaded benchmarks. But if you're concerned about energy bills, emissions, fanless computing or all day battery life then performance per watt matters even on x86-64 desktop environments. From the article: parallelism results in power savings. Multiple threads working in parallel on a page-rendering job allow the CPU to complete the entire page in the same amount of time while running at a lower frequency.
ohitsdom 11y ago
Off topic, but about LWN.net in general: these simple site designs do not work when you use third-party ad services. You have the content in a plain, 1999 style format without CSS. Then on top and to the side, you have modern designed ads with animation. It's a very jaring contrast. I understand people like simple sites (especially on HN), but the reasons for having one are invalidated when you integrate third-party ads.
hitlin37 11y ago
commit to same api as CEF project is very nice feature. This will give application developer to choose between CEF or servo. I think many will give servo a try if it works fine.

101 points by vezzy-fnord 11y ago

This, along with the recent missteps Mozilla have been making (proprietary software included in the package, Cisco's h264 renderer, etc), remind me a lot of the Mozilla SeaMonkey days, when people were tired of bloat, and decided to give gecko a newer lighter body to live in. I'm hoping someone steps up to write a new lightweight servo frontend in rust.

slimsag 11y ago

> the team hopes to have an alpha release before the end of 2015. "I wouldn't recommend logging in to your bank with it," he said, "but it should be usable as a basic browser." What? Was this meant as a joke in relation to something else? -- Why shouldn't you log into banking sites with it?

thomasfoster96 11y ago
An alpha release of a new browser engine is likely to have quite a few security bugs. Don't risk your bank account details for the sake of testing a new browser engine.
- slimsag 11y ago
  Fair point. Not trying to minimize what you're saying -- But I am genuinely curious as to how you'd test such a vast code-base written by so many different people for security issue? e.g. how will 1.0 be any more secure than alpha aside from developers having more time to "run into" the security issues by sheer luck/accident? Maybe someone vet the code by hand -- or maybe they will use a security testing suite to automate it? If so, wouldn't it make sense to do that before accepting code that could potentially introduce security bugs?
  - toyg 11y ago
    > how you'd test such a vast code-base written by so many different people for security issue? I think their point is that correct, well-thought-out and well-tested code (i.e. doing exactly what it needs to do, without side effects and errors) will inherently be more secure than any hacked-together it-runs-ship-it MVP/alpha/demo release (which is what Servo is, at the moment). Security-specific tests would be done in the same way as they're done for any mainstream engine out there.
larsberg 11y ago
The comment was meant to be lighthearted, but on the serious side we both: 1) Probably won't have done the full sort of inspection of our SSL cert checking to really ensure you aren't being MITM'd. 2) We won't have a chemspill / 0-day security fix infrastructure in place, so we won't have a way to push down fixes to 0-day exploits in OpenSSL, the JS engine, etc. I'd love to be at a better point on those features by the end of this year, but it's not likely with our current roadmap & resourcing plan.

falcolas 11y ago

I have to admit, I'm surprised they have no plans to migrate Firefox over to Servo. It seems like a waste, considering that desktops and laptops could both benefit from the increase in parallelism.

logn 11y ago
The way I read it, they have no plans in 2015/2016. Longer-term, we plan to incrementally replace components in Gecko with ones written in Rust and shared with Servo. We are still evaluating plans to ship Servo as a standalone product, and are focusing on the mobile and embedded spaces rather than a full desktop browser experience in the next two years. https://github.com/servo/servo/wiki/Roadmap https://github.com/servo/servo/wiki/Roadmap
sp332 11y ago
Multi-threaded rendering is less of a win when a single desktop core is already pretty powerful. Servo is going to make a big difference on mobile platforms with multiple underpowered cores.
- pcwalton 11y ago
  That's not true. Layout is still often slow (multi-hundred ms) on desktop. You can notice that. Also powerful x86 CPUs are so good at shared-memory multithreading (cache coherency, large caches) that x86 is actually the best case for us (which is not to say we're bad on ARM, of course).
  - ksec 11y ago
    multi-hundred ms is slow.... But what is strange to me we have to go through a magnitude of handles and paralleling a browser engine to get to sub 100ms layout. Could we not further improve the current engine?
- petecox 11y ago
  A 3 Ghz P4 from 2005 way well blitz a Core-M from 2015 on certain single-threaded benchmarks. But if you're concerned about energy bills, emissions, fanless computing or all day battery life then performance per watt matters even on x86-64 desktop environments. From the article: parallelism results in power savings. Multiple threads working in parallel on a page-rendering job allow the CPU to complete the entire page in the same amount of time while running at a lower frequency.

ohitsdom 11y ago

Off topic, but about LWN.net in general: these simple site designs do not work when you use third-party ad services. You have the content in a plain, 1999 style format without CSS. Then on top and to the side, you have modern designed ads with animation. It's a very jaring contrast. I understand people like simple sites (especially on HN), but the reasons for having one are invalidated when you integrate third-party ads.

hitlin37 11y ago

commit to same api as CEF project is very nice feature. This will give application developer to choose between CEF or servo. I think many will give servo a try if it works fine.