Confirm
137
edits
Changes
Improve WebRender documentation
* Talk: [https://air.mozilla.org/bjacob-gfx-overview/ An overview of Gecko's graphics stack] (Benoit Jacob, 2014-08-12)
* Talk: [https://air.mozilla.org/jeff-muizelaar-2d-graphics/ 2D Graphics] (Jeff Muizelaar, 2014-10-14)
* Mozilla gfx blg's [technical](https://mozillagfx.wordpress.com/category/technical/) category.
==== WebRender vs Layers ====Currently there are two different paint rendering paths in Gecko. The new one is WebRender. Here's a highlevel summary "Layers" is the name of how it works: [https:the previous //hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-hownon-webrender-gets-rid-of-jank/]architecture.
Here's a very high level summary of how it works: [https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/] From a high level architectural point of view, the main differences are:* Layers separate rendering into a painting phase and a compositing phase which usually happen in separate processes. For WebRender, on the other hand, all of the rendering happens in a single operation.* Layers internally expresses rendering rendering commands through a traditional canvas-like immediate mode abstraction (Moz2D) which has several backends (some of which use the GPU). WebRender works directly at a lower and GPU-centric level, dealing in terms of batches, draw calls and shaders.* Layers code is entirely C++, while WebRender is mostly Rust with some integration glue in C++. ==== WebRender ==== * WebRender's main entry point is a display list. It is a description of a visible subset of the page produced by the layout module.* WebRender and Gecko's display list representations are currently different so there is a translation between the two.* The WebRender display list is serialized on the content process and sent to the process that will do the rendering (either the main process or the GPU process).* The rendering process deserializes the display list and builds a "Scene".* From this scene, frames can be built. Frames represent the actual drawing operations that need to be performed for content to appear on screen. A single scene can produce several frames, for example if an element of the scene is scrolled.* The Renderer consumes the frame and produces actual OpenGL drawing commands. Currently WebRender is based on OpenGL and on Windows the OpenGL commands are transparently turned into D3D ones using ANGLE. In the long run we plan to work with a vulkan-like abstraction called gfx-rs. The main phases in WebRender are therefore:* Display list building* Scene building* frame building* GPU commands execution All of these phases are performed on different threads. The first two happen whenever the layout of the page change or the user scrolls past the part of the page covered by the current scene. They don't necessarily happen at a high frequency. Frame building and GPU command execution, on the other hand, happen at a high frequency (the monitor's refresh rate during scrolling and animations), which means that they must fit in the frame budget (typically 16ms). In order to avoid going over the frame budget, frame building and GPU command execution can overlap. scene building and frame building can also overlap and it is possible to continue generating frames while a new scene is being built asynchronously. WebRender has a fallback mechanism called "Blob images" for content that it does not handle (for example some SVG drawing primitives). It consists in recording and serializing a list of drawing commands (the "blob") on the content process and sending it to WebRender along with the regular display list. Blobs are then turned into images on the CPU during the scene building phase. The most of WebRender treats blob images as regular images. Some important internal operations and data structures:* The clip-scroll tree (TODO)* The render task graph (TODO)* Culling (TODO)* Batching (TODO)* Picture-caching (TODO) ==== Painting/Rasterizing (Layers aka Non-WebRender) ====
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.
