| channel.rs |
|
6314 |
0 % |
| color.rs |
|
4885 |
72 % |
| debugger.rs |
|
9938 |
- |
| display_item.rs |
|
102187 |
50 % |
| display_list.rs |
|
114709 |
82 % |
| fast_transform.rs |
|
18333 |
84 % |
| font.rs |
|
12712 |
59 % |
| gradient_builder.rs |
|
6500 |
94 % |
| image.rs |
|
22044 |
58 % |
| interned_prims.rs |
Interned primitive scene descriptions.
These are the per-primitive "scene description" structs that `webrender`
interns (the `T` in its `PrimKey<T>` / `Internable` machinery). Their fields
are all api-resident, so they live here in `webrender_api` to let
content-process interning in the `DisplayListBuilder` hold them; `webrender`
re-exports each from its former home and keeps the `Internable` /
`InternablePrimitive` impls and per-frame templates (the trait and templates
are webrender-internal). Not part of the public API surface. |
10305 |
96 % |
| interning.rs |
Content-side interning for the display list builder.
An [`Interner`] lives in the `DisplayListBuilder` and is *retained across
builds*: it is deliberately not touched by `DisplayListBuilder::reset`. That
gives two kinds of de-duplication for free:
* **Within one build** - pushing the same item twice hashes to the same
entry and yields the same [`Handle`], so the item's data is written into
the display list once instead of once per occurrence.
* **Across builds** - an item that survives into the next display list is
still in the map, so it keeps the same handle and its data is not
re-transmitted at all.
Instead of the data, the display list carries a [`Handle`]: a slot index
plus the build in which the item was first interned. Because the handle is
stable for as long as the entry lives, an unchanged item produces identical
display list bytes from one build to the next.
The receiver keeps a slot-indexed store of the item data. It is fed by the
[`InternOps`] delta that [`Interner::end_build`] returns at the end of each
build: the adds minted during that build, and the removes produced by that
build's garbage collection. The receiver is a pure follower and never talks
back. Because it only ever follows, the deltas form a strict sequence -
every one has to be delivered, in order, or the two sides are out of step
for good.
A builder holds one interner per interned type, gathered in [`DlInterners`].
They are begun and ended together, bracketed by [`DlInterners::begin_build`]
and [`DlInterners::end_build`], and share one build number, so what crosses
the IPC boundary is a single [`DlDelta`] per display list: the builder's
identity, the build it closes, and one [`InternOps`] per type. The set of
types is the list in [`enumerate_dl_interned_types!`], which the receiver
mirrors field for field.
Garbage collection runs once per build, in `end_build`. An entry is dropped
once it has been absent from [`RETAIN_BUILDS`] consecutive display lists,
which frees its slot for re-use and emits a remove op. The delay is not
what keeps the receiver safe - it applies a remove only together with the
scene built from the list that no longer references the entry - it is
there so that content flickering an item in and out does not re-send it.
Garbage collection frees entries but not the capacity they occupied, so
after one very large scene the containers would otherwise stay sized for it
for the life of the builder. `end_build` therefore also counts the builds
since the interner last filled more than half its capacity, and once that
reaches [`SHRINK_AFTER_BUILDS`] it reallocates the containers down to what
is live. The wait is hysteresis: a scene that alternates between large and
small should not pay for a reallocation each way. |
32601 |
79 % |
| key_types.rs |
Hashable building blocks for WebRender interning keys.
These are `f32`-bit-hashed / `Au`-quantized wrappers around geometry and
color types, used as fragments of the interning keys for primitives (and,
going forward, clips and other interned items). They live in `webrender_api`
so that keys built in the content process can reference only api-resident
types; `webrender` re-exports them from their former homes. |
21339 |
86 % |
| lib.rs |
The `webrender_api` crate contains an assortment types and functions used
by WebRender consumers as well as, in many cases, WebRender itself.
This separation allows Servo to parallelize compilation across `webrender`
and other crates that depend on `webrender_api`. So in practice, we put
things in this crate when Servo needs to use them. Firefox depends on the
`webrender` crate directly, and so this distinction is not really relevant
there. |
31260 |
81 % |
| prim_geometry.rs |
Primitive geometry simplification / gradient optimization helpers.
These are pure, behaviour-neutral geometry functions that simplify a
repeated/tiled primitive and pre-clip/optimize gradients before they are
handed to the GPU. They operate only on api-resident types so that they can
be shared between `webrender` (frame/scene building) and content-process
interning in the `DisplayListBuilder`; `webrender` re-exports them from their
former homes. Not part of the public API surface. |
20212 |
99 % |
| tile_pool.rs |
|
5961 |
95 % |
| units.rs |
A collection of coordinate spaces and their corresponding Point, Size and Rect types.
Physical pixels take into account the device pixel ratio and their dimensions tend
to correspond to the allocated size of resources in memory, while logical pixels
don't have the device pixel ratio applied which means they are agnostic to the usage
of hidpi screens and the like.
The terms "layer" and "stacking context" can be used interchangeably
in the context of coordinate systems.
See also webrender/doc/coordinate-spaces.md |
12416 |
58 % |