Subject: General Tech | February 17, 2014 - 08:10 AM | Scott Michaud
Tagged: web browser, Google Chrome, chromium
This stutter was 628 milliseconds, or about 38 consecutive frames at 60 FPS.
Image Credit: Chromium Project Blog
Web browsers are designed under the assumption that a single thread of instructions will weave through every task, one by one, until everything is done. At some point, since the early 1990s, computers have been give multiple cores (and some of those designs can have multiple threads shoved through at once). The problem is now that, since "Task A" was designed to occur before "Task B", doing them separately... can break stuff good.
A simplified browser execution flowchart. Execution follows the arrow.
Image Credit: Mozilla
In case you are wondering, Mozilla started to move compilation to a background thread as of Firefox 21. Firefox 29 will move the entire just-in-time (JIT) compilation process off the main thread. This is currently in their "Aurora" release channel. To the rest of the world: it's an alpha.
This optimization is currently available in Google Chrome Beta (33).
Subject: General Tech, Mobile | April 6, 2013 - 09:47 PM | Scott Michaud
Tagged: webkit, Blink, Android, Google Chrome, ChromeOS
There once was a web browser named Konqueror which was quite common in the Linux community. At its core was the KHTML rendering engine, a nice standards-compliant layout package; KHTML was so nice that Apple decided to create WebKit based on it. Since then, WebKit has been the basis of Google Chrome and other applications such as Steam as of a few years ago.
And even though the project maybe never be done, Google stuck a fork in it.
Blink is a new layout engine, based on WebKit, soon to be implemented in Google Chrome. By soon, I mean practically the next release. It stands to reason, too: a forked project by definition starts out looking nearly identical because they both start from the same point. The two projects will be able to evolve in different directions as each begin to differ in needs and desires.
So what does it mean? Firstly, web developers do not need to worry about a new vendor-prefix until at least Google starts to worry about one. According to their above Q&A, they currently seem more interested in reducing prefix support rather than adding new ones. Personally, I expect that at some point they will likely need to add some as standards evolve.
In terms of the future: I feel that multiple rendering engines will only be better for the future of the web. Sure, it can be difficult for web developers to test their products across a variety of devices but that is a drop in the bucket compared to the misery caused when a dominant player gets complacent. A noncompeting player will stop innovating and maybe pull away from open standards.
Then again this pretty much always happens: no-one is satisfied with monopolies. Thankfully the WebKit license made it easy for dissatisfied parties to take action. In turn, WebKit can benefit from many of these developments at their leisure, particularly before their products look too dissimilar.