Programmed from http://www.chromium.org/blink
About blink
Google Chrome/chromium has been using WebKit (WebCore) as the HTML/CSS rendering engine since its launch. WebKit was previously developed by Apple by the khtml project fork for the web engine of the Safari browser. Due to loose protocols, lightweight design, and convenient embedded APIs in applications, WebKit has become popular. Besides Google Chrome/chromium and Safari, WebKit has been deployed on mobile terminals (Symbian s60, Android, integrate with Toolkit (GTK +, qt4)
All have good results.
Although many of the above are often referred to as WebKit, they actually use their own WebKit branches or compile-time options, which makes the final rendering results quite different. However, in general, the WebKit community is still relatively harmonious, and various Members have also made efforts to maintain compatibility, until the launch of webkit2 with OS X lion in 2010. Due to the conflict between the process isolation implemented by webkit2 on The WebCore layer and the sandbox Design of Google Chrome/chromium to some extent, Google Chrome/chromium has been stuck
WebKit, which is compatible with the main webkit2 in backport mode. Obviously, this increases the complexity of WebKit and chromium, and affects the architecture porting of chromium to a certain extent.
For the above reasons, Google decided to generate its own blink web engine from WebKit fork:
At this stage, we will focus on streamlining the internal structure and delete about 7000 files and 4.5 million lines of webkit2 compatible code.
In the future, we will focus on improving the DOM architecture and use JavaScript to implement Dom.
Improve security and implement out-of-process iframes.
For opera, which announced that it had abandoned its own rendering engine and followed chromium earlier this year, its developers immediately announced that opera will switch to the blink engine.
[1] The advent of Google blink will allow it to part more thoroughly with other WebKit browser developers, including Apple, Nokia, and blackberry. This means that there are now four rendering engines online: WebKit, blink, Trident, and gecko. For users, the difference in the rendering engine means they will get different results when opening the same page in different browsers-especially on mobile devices. Google wrote in a blog article: "We know that the emergence of new rendering engines will have a significant impact on Web browsing ." But Google added that it believes that multiple rendering engines "can promote innovation and improve the health of the entire network ecosystem ." Google is at great risk. According to netmarketshare data, Chrome is currently one of the most commonly used browsers on desktops. According to statcounter statistics, Chrome is currently the most common browser for desktops. Netmarketshare counts the number of visitors, while statcounter only counts clicks. If Google's new strategy fails, chrome
The browser's dominance may not be guaranteed. WebKit is still being used in the version description of chrome 28 development, and blink has been replaced in the latest chrome 28.0.1469.0. Blink architecture changesAt the beginning of the Chrome project, our goal was to make as few changes to WebKit as possible, so it was easy to merge with WebKit code.
For blink, We are excited to create code with greater architecture flexibility without worrying about other WebKit users.
We plan to add an "out-of-process"
Iframes ", which enables chromium to separate an independent part of the page into a separate sandbox process.
To achieve this, you need to modify the IFRAME processing of WebKit a lot.
In another example, we will fix the network code to make it smaller and faster. Currently, the network code in WebKit is limited by the old Mac WebKit API and cannot be changed.
Chromium has been working around it for many years, but the work around it is fragile and has many bugs.
In blink, we will use the new network code without the need to enforce consistency with other WebKit users.
Finally, we even want to implement the entire DOM tree with javascip. This will make JavaScript Access faster. However, this requires a lot of rewriting of the WebKit DOM implementation. This is closer to WebKit's support for two Javascript Engines at the same time.
Other changes we are considering
- Allow WebCore to support multi-process history (currently, it assumes that the same process synchronizes History)
- Delete the widget tree (a constraint of MAC webkit1)
- Separate WebCore from different modules
- The Sandbox platform API will be used directly to replace the current WebCore/Platform
- Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day? Thank you)
- Try to move the Dom to the JS Stack
- Added multi-core multiplexing (such as HTML parsing, style engine, and JavaScript parsing)
- Remove ambiguous parts in the Dom or remove unnecessary compatibility due to backward compatibility.
- Use modern and faster tcmalloc (a multi-thread memory allocation software compiled by Google, instead of malloc) to run through Mac chrome
- Try parallel Layout
- Avoid Memory leakage by removing the scriptvalue/scriptstate Abstraction
- Use webidl to replace webkitidl and remove JavaScript binding code
- Using dom3 events/[Dom] UI events to speed up WebCore
