Skip to content
Dzmitry Malyshau edited this page Apr 10, 2017 · 4 revisions

Overview

Please refer to Path to Screen for the detailed initialization sequence description.

RenderBackend:

  • owns ResourceCache, which in turn owns TextureCache
  • build_scene flattens the StackingContext and allocates all the GPU data into textures.
  • render() builds a new Frame by culling the primitives against layers/tiles and filling up the batch instance data
  • publish() sends a frame over the result channel
  • any messages requiring feedback provide a sender themselves

Render Pass

All the work in a produced Frame is based off a task tree. This tree is composed by the RB and flattened out into passes before sending to the Renderer. A RenderPass:

  • has list of tasks that are independent of each other
  • all these tasks depend on some tasks in the previous pass
  • is rendered into a texture array layer by layer. The previous pass's texture is seen as sCache texture sampler.

Each texture array is an atlas of the target regions that were requested by the tasks (see RenderTaskLocation::Dynamic). The width and height are the same across all passes, and the depth is as little as required to fit all the target regions.

Let's take the blur filter for example. Considering the source of the blur stored in pass[0] (supposing, a text run has been rendered there), the vertical pass will be done in pass[1]. Since the horizontal pass works off the vertical pass results, it will be assigned to the next pass[2].

Task Lifetime

  1. RenderTask gets created in ScreenTile::compile() and put into the tree with the root of CompiledScreenTile::main_render_task.
  2. CompiledScreenTile::build() is given a Vec<RenderPass>, and it starts calling RenderTask::assign_to_passes. The topmost tasks going to the last pass, their children going to the one below it, and so forth. We assume (and guarantee) that the number of passes equals to the depth of the tree. Tasks end up being stored in RenderPass::tasks.
  3. RB composes a Frame containing our render passes and sends it to the Renderer.
  4. RenderPass::build creates render targets if needed for the tasks storage allocation and calls RenderTarget::add_task, which dissects the task to be consumed by one of the batchers: Alpha, Clip, or Blur.
  5. Renderer::draw_target goes through the batchers and issues the specific draw calls.