Module webrender::renderer

The high-level module responsible for interfacing with the GPU.

Much of WebRender’s design is driven by separating work into different threads. To avoid the complexities of multi-threaded GPU access, we restrict all communication with the GPU to one thread, the render thread. But since issuing GPU commands is often a bottleneck, we move everything else (i.e. the computation of what commands to issue) to another thread, the RenderBackend thread. The RenderBackend, in turn, may delegate work to other thread (like the SceneBuilder threads or Rayon workers), but the Render-vs-RenderBackend distinction is the most important.

The consumer is responsible for initializing the render thread before calling into WebRender, which means that this module also serves as the initial entry point into WebRender, and is responsible for spawning the various other threads discussed above. That said, WebRender initialization returns both the Renderer instance as well as a channel for communicating directly with the RenderBackend. Aside from a few high-level operations like ‘render now’, most of interesting commands from the consumer go over that channel and operate on the RenderBackend.

Space conversion guidelines

At this stage, we shuld be operating with DevicePixel and FramebufferPixel only. “Framebuffer” space represents the final destination of our rendeing, and it happens to be Y-flipped on OpenGL. The conversion is done as follows:

• for rasterized primitives, the orthographics projection transforms the content rectangle to -1 to 1
• the viewport transformation is setup to map the whole range to the framebuffer rectangle provided by the document view, stored in DrawTarget
• all the direct framebuffer operations, like blitting, reading pixels, and setting up the scissor, are accepting already transformed coordinates, which we can get by calling DrawTarget::to_framebuffer_rect

Re-exports

• pub use debug::DebugRenderer;
• pub use shade::Shaders;
• pub use shade::SharedShaders;
• pub use vertex::desc;
• pub use vertex::VertexArrayKind;
• pub use vertex::MAX_VERTEX_TEXTURE_WIDTH;
• pub use gpu_buffer::GpuBuffer;
• pub use gpu_buffer::GpuBufferF;
• pub use gpu_buffer::GpuBufferBuilderF;
• pub use gpu_buffer::GpuBufferI;
• pub use gpu_buffer::GpuBufferBuilderI;
• pub use gpu_buffer::GpuBufferAddress;
• pub use gpu_buffer::GpuBufferBuilder;

Modules

• debug 🔒
• gpu_buffer 🔒
• gpu_cache 🔒
• init 🔒
• shade 🔒
• tests 🔒
• upload 🔒
  This module contains the convoluted logic that goes into uploading content into the texture cache’s textures.
• vertex 🔒
  Rendering logic related to the vertex shaders and their states, uncluding

Structs

• BufferDamageTracker 🔒
  Tracks buffer damage rects over a series of frames.
• CacheTexture 🔒
• CpuProfile
• DebugFlags
  Flags to enable/disable various builtin debugging tools.
• DebugOverlayState 🔒
  Information about the state of the debugging / profiler overlay in native compositing mode.
• FullFrameStats
  The cumulative times spent in each painting phase to generate this frame.
• GpuProfile
• GraphicsApiInfo
• PipelineInfo
• PlainExternalResources 🔒
• PlainRenderer 🔒
• PlainTexture 🔒
• RenderResults
  Return type from render(), which contains some repr(C) statistics as well as some non-repr(C) data.
• Renderer
  The renderer is responsible for submitting to the GPU the work prepared by the RenderBackend.
• RendererStats
  Some basic statistics about the rendered scene, used in Gecko, as well as in wrench reftests to ensure that tests are batching and/or allocating on render targets as we expect them to.
• ShaderPrecacheFlags
  Flags that control how shaders are pre-cached, if at all.
• TextureResolver 🔒
  Helper struct for resolving device Textures for use during rendering passes.

Enums

• BlendMode
• FramebufferKind 🔒
• GraphicsApi
• PartialPresentMode 🔒
  The selected partial present mode for a given frame.
• RendererError
• ShaderColorMode
• TextureSampler 🔒
  Enumeration of the texture samplers used across the various WebRender shaders.

Constants

• BLOCKS_PER_UV_RECT
  Number of GPU blocks per UV rectangle provided for an image.
• GPU_SAMPLER_TAG_ALPHA 🔒
• GPU_SAMPLER_TAG_OPAQUE 🔒
• GPU_SAMPLER_TAG_TRANSPARENT 🔒
• GPU_TAG_BLIT 🔒
• GPU_TAG_BLUR 🔒
• GPU_TAG_BRUSH_BLEND 🔒
• GPU_TAG_BRUSH_IMAGE 🔒
• GPU_TAG_BRUSH_LINEAR_GRADIENT 🔒
• GPU_TAG_BRUSH_MIXBLEND 🔒
• GPU_TAG_BRUSH_OPACITY 🔒
• GPU_TAG_BRUSH_SOLID 🔒
• GPU_TAG_BRUSH_YUV_IMAGE 🔒
• GPU_TAG_CACHE_BORDER 🔒
• GPU_TAG_CACHE_CLIP 🔒
• GPU_TAG_CACHE_CONIC_GRADIENT 🔒
• GPU_TAG_CACHE_FAST_LINEAR_GRADIENT 🔒
• GPU_TAG_CACHE_LINEAR_GRADIENT 🔒
• GPU_TAG_CACHE_LINE_DECORATION 🔒
• GPU_TAG_CACHE_RADIAL_GRADIENT 🔒
• GPU_TAG_CLEAR 🔒
• GPU_TAG_COMPOSITE 🔒
• GPU_TAG_INDIRECT_MASK 🔒
• GPU_TAG_INDIRECT_PRIM 🔒
• GPU_TAG_PRIMITIVE 🔒
• GPU_TAG_PRIM_SPLIT_COMPOSITE 🔒
• GPU_TAG_PRIM_TEXT_RUN 🔒
• GPU_TAG_SCALE 🔒
• GPU_TAG_SETUP_DATA 🔒
• GPU_TAG_SETUP_TARGET 🔒
• GPU_TAG_SVG_FILTER 🔒
• TEXTURE_CACHE_DBG_CLEAR_COLOR
  The clear color used for the texture cache when the debug display is enabled. We use a shade of blue so that we can still identify completely blue items in the texture cache.
• VERTEX_DATA_TEXTURE_COUNT
  The size of the array of each type of vertex data texture that is round-robin-ed each frame during bind_frame_data. Doing this helps avoid driver stalls while updating the texture in some drivers. The size of these textures are typically very small (e.g. < 16 kB) so it’s not a huge waste of memory. Despite that, this is a short-term solution - we want to find a better way to provide this frame data, which will likely involve some combination of UBO/SSBO usage. Although this only affects some platforms, it’s enabled on all platforms to reduce testing differences between platforms.

Functions

• flag_changed 🔒
• should_skip_batch 🔒