
Parallel page rendering with Mozilla Servo - vezzy-fnord
https://lwn.net/Articles/647969/
======
falcolas
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.

~~~
sp332
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
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
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?

------
anonbanker
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
> 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
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
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
_> 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.

------
hitlin37
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.

------
ohitsdom
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.

