Doesn't intel quicksync help mitigate this?
QuickSync
could help. It'd depend on a few things:
1) How easy would it be to integrate into the OS?
2) What are its limitations? (ASICs like these typically only work up to a certain bitrate/resolution/input format/output format/etc.)
----------
Hmmm. I didn't really mean to say packets, but objects, like html, each image, any live feeds. If webkit were to run 3-4 instances of Java on the basis that if you have 4 processors you probably also have a bit more memory and storage associated with that hardware.
FB code is far from optimized for resources and yes it is annoying it keeps feeding down a single page of "infinite scroll". Recently I was on a FB page and wanted to click on one of those items on the very bottom of the page. It was hard to catch! That is a UI error.
When I am on finance.google.com and am watching a stock live, it often hangs and fails to refresh after I work with a variety of other browser tabs or windows. The process sharing or threading is weak on browser to date.
I do think having the browser initiate more than one instance of java (or gag, flash) could speed things up quite a bit.
Rocketman
I see what you mean.
For plugins like Flash, Quicktime, and Java (not javascript), they're already on a separate process, at least in Chrome and Safari on Mac. Why they don't instantiate more than one of each, I'm not sure. But rarely does that peak out for me anyways so it wouldn't have helped.
The plugins arn't what's causing the behavior on facebook.
The bottleneck is what I mentioned above: Javascript. Since the design allows for only one javascript interpreter per page, there's no way to run more than one instance per page to spread out the load.
This isn't something that's a design of the browser, but rather how javascript itself is supposed to function.
As for the finance.google.com problem you're observing, there's multiple possible explanations:
1) The stock graph is Flash and written poorly. Partly because it's written in Flash.
2) The recent quotes on the left is in javascript and probably also written poorly. May not have handled a delay in update retrieval all that well. (maybe bad internet connection?)