Path to the Screen

In this document, we'll describe the path WR (short for WebRender) takes to get actual pages on screen.

Initializing and providing the data

Renderer::new() creates the WR instance with the following components:

• RenderBackend (RB). It's not returned from the function, but instead put to work in a separate thread and communicate via messages with the following objects.
• RenderApiSender, needed to produce RenderApi instances, each with a unique namespace.
• Renderer owns the graphics context and does the actual rendering.

When issuing commands through RenderApi, they get serialized and sent over the IPC channel (not necessary through the IPC boundary - controlled by a cargo feature) to RB.

Resource management

RenderApi attempts to be consistent with regards to the resource API:

1. generate_something_key() - get a new unique key that is not yet associated with any data.
2. add_something(key, ...) - associate the key with actual data (e.g. texels of an image).
3. push_something_else - there can be several methods that use our key in one way or another. For example, an image can be provided as a part of ClipRegion for any primitive.
4. update_something(key, ...) - update a part of a resource associate with the key.
5. delete_*(key) - destroy the associated resource with all its contents.

Setting pipelines and display lists (DL)

A frame is considered complete when it has a root pipeline, set by set_root_pipeline, and a display list, set by set_display_list. The frame doesn't get rendered until generate_frame is called, or any sort of scrolling is requested (scroll, scroll_layer_with_id, etc).

When calling generate_frame, the user can provide a list of new values for the animated properties of a frame. This doesn't force the re-generation of a frame by the RenderBackend, and re-uses the last formed frame that Renderer received.