| batch.rs |
|
139492 |
| border.rs |
|
50433 |
| box_shadow.rs |
|
10880 |
| capture.rs |
|
4668 |
| clip_scroll_tree.rs |
|
30736 |
| clip.rs |
|
61628 |
| debug_colors.rs |
|
14765 |
| debug_font_data.rs |
|
117993 |
| debug_render.rs |
|
12106 |
| debug_server.rs |
|
11854 |
| device |
|
3 |
| display_list_flattener.rs |
|
125041 |
| ellipse.rs |
|
6076 |
| filterdata.rs |
|
7594 |
| frame_builder.rs |
|
24241 |
| freelist.rs |
A generic backing store for caches.
`FreeList` is a simple vector-backed data structure where each entry in the
vector contains an Option<T>. It maintains an index-based (rather than
pointer-based) free list to efficiently locate the next unused entry. If all
entries are occupied, insertion appends a new element to the vector.
It also supports both strong and weak handle semantics. There is exactly one
(non-Clonable) strong handle per occupied entry, which must be passed by
value into `free()` to release an entry. Strong handles can produce an
unlimited number of (Clonable) weak handles, which are used to perform
lookups which may fail of the entry has been freed. A per-entry epoch ensures
that weak handle lookups properly fail even if the entry has been freed and
reused.
TODO(gw): Add an occupied list head, for fast iteration of the occupied list
to implement retain() style functionality. |
7977 |
| gamma_lut.rs |
!
Gamma correction lookup tables.
This is a port of Skia gamma LUT logic into Rust, used by WebRender.
|
13051 |
| glyph_cache.rs |
|
6165 |
| glyph_rasterizer |
|
3 |
| gpu_cache.rs |
Overview of the GPU cache.
The main goal of the GPU cache is to allow on-demand
allocation and construction of GPU resources for the
vertex shaders to consume.
Every item that wants to be stored in the GPU cache
should create a GpuCacheHandle that is used to refer
to a cached GPU resource. Creating a handle is a
cheap operation, that does *not* allocate room in the
cache.
On any frame when that data is required, the caller
must request that handle, via ```request```. If the
data is not in the cache, the user provided closure
will be invoked to build the data.
After ```end_frame``` has occurred, callers can
use the ```get_address``` API to get the allocated
address in the GPU cache of a given resource slot
for this frame. |
32602 |
| gpu_glyph_renderer.rs |
GPU glyph rasterization using Pathfinder. |
11872 |
| gpu_types.rs |
|
21143 |
| hit_test.rs |
|
20838 |
| image.rs |
|
25375 |
| intern.rs |
The interning module provides a generic data structure
interning container. It is similar in concept to a
traditional string interning container, but it is
specialized to the WR thread model.
There is an Interner structure, that lives in the
scene builder thread, and a DataStore structure
that lives in the frame builder thread.
Hashing, interning and handle creation is done by
the interner structure during scene building.
Delta changes for the interner are pushed during
a transaction to the frame builder. The frame builder
is then able to access the content of the interned
handles quickly, via array indexing.
Epoch tracking ensures that the garbage collection
step which the interner uses to remove items is
only invoked on items that the frame builder thread
is no longer referencing.
Items in the data store are stored in a traditional
free-list structure, for content access and memory
usage efficiency.
The epoch is incremented each time a scene is
built. The most recently used scene epoch is
stored inside each handle. This is then used for
cache invalidation. |
12061 |
| internal_types.rs |
|
18465 |
| lib.rs |
!
A GPU based renderer for the web.
It serves as an experimental render backend for [Servo](https://servo.org/),
but it can also be used as such in a standalone application.
# External dependencies
WebRender currently depends on [FreeType](https://www.freetype.org/)
# Api Structure
The main entry point to WebRender is the [`crate::Renderer`].
By calling [`Renderer::new(...)`](crate::Renderer::new) you get a [`Renderer`], as well as
a [`RenderApiSender`](api::RenderApiSender). Your [`Renderer`] is responsible to render the
previously processed frames onto the screen.
By calling [`yourRenderApiSender.create_api()`](api::RenderApiSender::create_api), you'll
get a [`RenderApi`](api::RenderApi) instance, which is responsible for managing resources
and documents. A worker thread is used internally to untie the workload from the application
thread and therefore be able to make better use of multicore systems.
## Frame
What is referred to as a `frame`, is the current geometry on the screen.
A new Frame is created by calling [`set_display_list()`](api::Transaction::set_display_list)
on the [`RenderApi`](api::RenderApi). When the geometry is processed, the application will be
informed via a [`RenderNotifier`](api::RenderNotifier), a callback which you pass to
[`Renderer::new`].
More information about [stacking contexts][stacking_contexts].
[`set_display_list()`](api::Transaction::set_display_list) also needs to be supplied with
[`BuiltDisplayList`](api::BuiltDisplayList)s. These are obtained by finalizing a
[`DisplayListBuilder`](api::DisplayListBuilder). These are used to draw your geometry. But it
doesn't only contain trivial geometry, it can also store another
[`StackingContext`](api::StackingContext), as they're nestable.
[stacking_contexts]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
|
6553 |
| picture.rs |
A picture represents a dynamically rendered image. It consists of:
A number of primitives that are drawn onto the picture.
A composite operation describing how to composite this
picture into its parent.
A configuration describing how to draw the primitives on
this picture (e.g. in screen space or local space).
|
133324 |
| platform |
|
3 |
| prim_store |
|
8 |
| print_tree.rs |
|
2774 |
| profiler.rs |
|
43253 |
| record.rs |
|
2855 |
| render_backend.rs |
The high-level module responsible for managing the pipeline and preparing
commands to be issued by the `Renderer`.
See the comment at the top of the `renderer` module for a description of
how these two pieces interact. |
75787 |
| render_task.rs |
|
90828 |
| renderer.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` |
231264 |
| resource_cache.rs |
|
89144 |
| scene_builder.rs |
|
25149 |
| scene.rs |
|
9661 |
| screen_capture.rs |
Screen capture infrastructure for the Gecko Profiler and Composition Recorder. |
14357 |
| segment.rs |
|
42269 |
| shade.rs |
|
33026 |
| spatial_node.rs |
|
36607 |
| storage.rs |
|
3551 |
| texture_allocator.rs |
|
9941 |
| texture_cache.rs |
|
69757 |
| tiling.rs |
|
62184 |
| util.rs |
|
39510 |