Hacker News Reader

Comment by tbrock | Hacker News Reader

Is multithreaded rendering really the next big browser breakthrough? If so, are Google and Apple also working on similar projects?

View on HN

I remember hearing that the Blink folks were looking into it, but that in general it is really hard to do the kind of stuff that Servo does because CeePlusPlus.

And Servo is built from the ground up. Putting (decent) threading into Blink/WebKit would be a huge undertaking.

Early reports look really promising. It's hard to tell when Servo doesn't implement the full web platform, but even with a substandard network stack, Servo is _fast_.

I remember Brendan Eich saying that you can bet on it. But he included Microsoft in that statement and given all the work on forking Trident into EdgeHTML I'm pretty sure they weren't.

Apple and Google could very well have secret projects going on for such a thing though.

I don't think it will feel like a breakthrough. On the desktop the network is the bottleneck, not the rendering. However, it might save energy on mobile multicore devices. That is nice, because on my smart phone the browser really drains the battery.

> On the desktop the network is the bottleneck, not the rendering.

That's pretty oversimplified. For lots of workloads—e.g. interacting with widgets on the page, composing emails/etc, scrolling, opening pop-out menus, interacting with Google Maps—the rendering (broadly speaking) is the bottleneck.

In fact, I'm of the opinion that improving layout and graphics performance is the single biggest thing we can do to make Web apps not feel slow compared to their native counterparts. People still (often quite rightly) feel that the Web is slower than native (however "native" is defined). The difference is unlikely to be network-related, and it's unlikely to be JavaScript either for most apps—JS performance may not be at C++-level yet (though asm.js will get there in time), but it's certainly on par with Objective-C and Java/Dalvik. The problem is mostly styling, layout, and graphics in my view: how to get from the DOM to rendered pixels as quickly as possible. Those are, not coincidentally, what Servo has focused on.

So does that mean the experiment to use it in B2G has a more utilitarian purpose than just stretching the limits of the engine?

I disagreed. I don't usually notice rendering performance problem. I only noticd Javascript performance. But that's because I have 1,000 tabs open, and each tab is running 100 Javascripts due to modern websites desired to be dynamic and 'animating' all the fucking time.

The way to solve this is NOT to make Javascript faster. The way to solve this is also NOT to force websites to run few numher of Javascripts at the same time.

The way to solve this is to virtualized all the tabs. In other word, tabs that are not visible should be unloaded (allow the user to right click a tab and "Keep This Tab Loaded"). This saves on CPU usage and RAM usages.

In summary, rendinger performaces is in the milliseconds, compare to running 10,000 Javascripts, which is in the minutes.

> However, it might save energy on mobile multicore devices.

Multicore devices shut down cores to save energy. How would multithreaded rendering save energy?

Getting work done faster lets you put the CPU to sleep faster.

Processor power use scales with frequency as well. See [0], specifically the 'Low Memory and Power Devices' section, which shows power savings running 4 cores at lower frequency versus 1 core at max frequency. I think they eventually decided that running at max frequency on all processors and sleeping wound up being most efficient but that's my memory and could be completely incorrect.

[0] http://blogs.s-osg.org/servo-adapting-c-to-work-on-the-web/

In theory, more parallelism can give you a) more work done in the same time, b) same work done in less time, or c) same work done in the same time using less energy due to lower frequency.

This isn't true anymore. There's plenty of sites that are just sluggish even after they loaded. Netflix, for instance. Or any modern "content" site. It's really quite intolerable, especially as there's no new functionality in these sites. It's not like my experience on Netflix, for instance, has improved in a decade (player UI aside, which still lags behind any real playback program.)

The rendering is a bottleneck that's less tolerated than network latency. For example in apps users tolerate a loading spinner more than they tolerate 300ms of latency when clicking on buttons or when scrolling. It's because of what users have been trained to expect. A loading spinner is considered normal, whereas a small barely-perceptible latency is interpreted as broken behavior when doing actions that in the minds of users should have an immediate response. Of course, for simple websites the rendering time is totally irrelevant. But nowadays we're running apps in our browser. And for example I've seen my browser brought to its knees by pages displaying charts.

I still see security as the best feature of a new Firefox written in Rust.

Eventual security, perhaps, but that's a loooong stretch-goal. The fact of the matter is, even Servo, which is written-from-scratch and lacks all the UI goodies, is only a fraction Rust. It'll be a long time before supported libraries could be rewritten and rust, and I reckon a rewrite of all these things is likely to cause more new human-error security flaws than it will eliminate pointer/memory related security issues. In the (very) long run, though, I agree.

What percentage of critical vulnerabilities in Firefox were due to memory safety issues? Is it changing dramatically?

> What percentage of critical vulnerabilities in Firefox were due to memory safety issues?

The vast majority of them.

(I haven't done the exact analysis, but I have performed similar ones and the fact that memory safety issues dominated was clear. Note also that I am not claiming that solving memory safety issues is a panacea. "Merely" that we're defending against the vast majority of critical security vulnerabilities.)

I don't think that's true for layout/graphics at least. Generally, the worst that can go wrong for incorrect layout, beyond memory safety, is that a box ends up in the wrong place, or the engine harmlessly panics with a crashed tab. There can be spoofing issues with boxes being drawn in the wrong place, but those are minor compared to RCE.

I think it's less of a big breakthrough and more of a way to validate that Rust is the Right Thing for certain hard problems.

Reply on news.ycombinator.com