| debug.rs |
|
13232 |
| gpu_buffer.rs |
TODO:
Recycle GpuBuffers in a pool (support return from render thread)
Efficiently allow writing to buffer (better push interface)
Support other texel types (e.g. i32)
|
10836 |
| gpu_cache.rs |
|
20259 |
| init.rs |
|
30911 |
| mod.rs |
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` |
235793 |
| shade.rs |
|
53318 |
| upload.rs |
This module contains the convoluted logic that goes into uploading content into
the texture cache's textures.
We need to support various combinations of code paths depending on the quirks of
each hardware/driver configuration:
- direct upload,
- staged upload via a pixel buffer object,
- staged upload via a direct upload to a staging texture where PBO's aren't supported,
- copy from the staging to destination textures, either via blits or batched draw calls.
Conceptually a lot of this logic should probably be in the device module, but some code
here relies on submitting draw calls via the renderer. |
32869 |
| vertex.rs |
Rendering logic related to the vertex shaders and their states, uncluding
- Vertex Array Objects
- vertex layout descriptors
- textures bound at vertex stage |
36696 |