4 ms·

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 multico

by qznc 11y ago

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.

pcwalton 11y ago
> 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.
- bobajeff 11y ago
  So does that mean the experiment to use it in B2G has a more utilitarian purpose than just stretching the limits of the engine?
- thelastguy 11y ago
  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.
_pmf_ 11y ago
> However, it might save energy on mobile multicore devices. Multicore devices shut down cores to save energy. How would multithreaded rendering save energy?
- pcwalton 11y ago
  Getting work done faster lets you put the CPU to sleep faster.
- grayrest 11y ago
  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/ http://blogs.s-osg.org/servo-adapting-c-to-work-on-the-web/
- qznc 11y ago
  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.
MichaelGG 11y ago
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.)
bad_user 11y ago
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.

by qznc 11y ago

pcwalton 11y ago

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

bobajeff 11y ago
So does that mean the experiment to use it in B2G has a more utilitarian purpose than just stretching the limits of the engine?
thelastguy 11y ago
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.

_pmf_ 11y ago

> However, it might save energy on mobile multicore devices. Multicore devices shut down cores to save energy. How would multithreaded rendering save energy?

pcwalton 11y ago
Getting work done faster lets you put the CPU to sleep faster.
grayrest 11y ago
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/ http://blogs.s-osg.org/servo-adapting-c-to-work-on-the-web/
qznc 11y ago
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.

MichaelGG 11y ago

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

bad_user 11y ago

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.