浏览器中的引擎 - 它们如何交互？

Question

I've been trying to learn more under the hood when it comes to Web Development, specifically JavaScript, and how the different engines interact with the JavaScript engine. For example, I know that the Rendering Engine is interacting, HTTP Requests, etc. I was just wondering, when the JavaScript Engine has to send data to another engine, such as the rendering engine, how much more computing has the JavaScript engine done by the time that data gets there?

Answer 1

The Web is a standardised platform running on the application layer of the Internet Protocol Suite .

It is a hypermedia system consisting of a protocol (HTTP), a markup language, a styling language (CSS) and a browser API (the Web API).

The Web was a development upon earlier hypermedia systems like HyperCard and uses a similar single-threaded, event-oriented rendering process.

The crux of your question is "how do the various parts of the browser interact to render a web page?"

The answer is a mixture of vendor-specific implementation and standardised behaviour defined by the standards bodies W3C and WHATWG.

The rendering process at a high level might be something like this:

The inbound message is exposed to the browser application by the operating system's networking substem (which in turn received the stream over the TCP IPS transport-layer) as a stream of bytes encoded using UTF-8.

Thus the networking subsystem of the browser receives an inbound UTF-8 encoded octet stream.

The browser will likely process the inbound stream of bytes on a thread or process other than that coordinating the rendering of the UI to avoid locking up the browser.

The browser understands the text-based HTTP protocol Tim Berners-Lee invented in 1989, and interprets the inbound bytes as an HTTP message.

The body of the message will correspond to the markup of the page. Once the page markup has been received it will be handed to a thread for rendering.

Starting at the top of the markup the browser rendering process will begin parsing according to an algorithm defined by the W3C/ WHATWG .

When JavaScript is encountered, it will typically be run immediately, but there are complicated rules about exactly what happens when.

When references to resources (eg. images, scripts, stylesheets) are encountered, requests for their download will be made. Some will block the rendering process, some will not.

When a piece of JavaScript is encountered, its evaluation will usually block the user interface. This is because the Web was designed to have a single thread of execution controlling the rendering of a page, and JavaScript is part of that process. As far as I know, multi-threaded user interface rendering systems are unusual because of their complexity (although I could be wrong on this).

So the browser will extract the JavaScript from the markup (or a linked script resource), and hand it to the JavaScript engine for evaluation. The JavaScript runtime is an application that enables the evaluation of a stack-based language. It has a stack and a heap and logic for converting JavaScript script into a form understood by the CPU.

The stack has zero or more stack frames on it. In JavaScript stack frames are called execution contexts. An execution context is like a bookmark in a book, it helps the runtime keep track of where it is in the execution of the script. Only when the stack is empty of execution contexts can the browser continue with its rendering work - so yes, running JavaScript typically blocks rendering.

Communication between the various browser subsystems (network, JavaScript runtime, rendering) will occur via the heap allocated to the browser process, or if the browser is multi-process, by inter-process communication mechanisms exposed by the particular operating system being used (eg. named pipes).

Once enough (according to the W3C specification) of the markup (HTML) and styles (CSS) and enough of the script (JavaScript) has been evaluated, rendering can begin.

Rendering is a vendor-specific process, but most browsers will be similar at a high level. Each HTML element is processed in turn. Chrome uses the following sequence for every element on the page:

1. The JavaScript that applies to the element is evaluated.
2. The CSS styles that apply to the element are evaluated.
3. The element is laid-out on the page accordingly.
4. The element is painted into a bitmap (colored pixels).
5. The element is composited. It's final appearance it calculated according to the impact of the different layers of other elements on the page.

This process might be repeated more than once on any given element, depending on the contents of the page and changes introduced dynamically by scripts.

Answer 2

Computers are normally able to perform billions of calculations every second. However, the rendering thread only updates 60 times normally (refresh rate/VSync), and network requests are much slower. Offloading them to thread is cheaper compared to being blocked by waiting.

An additional reason to offload drawing is to make the interface look snappy: even if something is running long in the JS thread, an offloaded rendering thread will still be responsive as normal.

Answer 3

Very roughly, this is how it goes:

• The browser gets the HTML page (or HTML data what was sent to it).
• Browser begins to interpret and process the page
• In the head section, if it sees any external linked files, such as JavaScript & CSS files, it initiates a load request immediately.
• If there is any JavaScript, either in the HTML, or in a linked file, the JavaScript is executed immediately , unless it takes advantage of the newer async option. This is why JavaScript normally includes an event handler for when the document has finished loading.
• The rest goes on …

Taking a break, note that the head stuff is processed as it is received, not later.

• The body content is processed, from top to bottom.
• While this is happening the DOM (Document Object Model — a sort of map of the contents) is created.
• HTML visible content is rendered.
• Any additional external data, such as images will initiate their own download requests. This content is loaded in parallel, rather than waiting . This is why badly designed HTML often leads to redrawing after images have been loaded.
• The CSS, which is loaded by now, is applied at the same time.

That's it for static content. There is one more stage, if you have JavaScript which changes content:

• JavaScript can change the content of the Document at any time.
• Often, but not always, changing the content can trigger a redraw. This will be needed if the change affects the layout.
• JavaScript can also change individual CSS styles of HTML elements. Again, this may trigger a redraw.