0bf19769e6
This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient. Previously, mix-blend mode was composed in the following way: 1. parent stacking context was forced to isolate 2. source picture is also isolated 3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache. 4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic: 1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible. 2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture 3. the instance of the backdrop picture is placed as a peer of the source picture (not a child) 4. if the backdrop is invisible, the source is drawn as a simple blit 5. otherwise, it's a draw call that reads from the isolated backdrop and source textures Note the differences: - parent stacking context is not isolated, but backdrop is - no framebuffer readback is involved - the source and backdrop pictures are rendered in parallel in a pass, improving the batching - we don't blend onto the backdrop while reading from the backdrop copy at the same time - the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings Differential Revision: https://phabricator.services.mozilla.com/D20608 --HG-- rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| ci-scripts | ||
| debugger | ||
| direct-composition | ||
| examples | ||
| webrender | ||
| webrender_api | ||
| webrender_build | ||
| wr_malloc_size_of | ||
| wrench | ||
| .gitignore | ||
| .taskcluster.yml | ||
| appveyor.yml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
| rustfmt.toml | ||
| servo-tidy.toml | ||
WebRender
GPU renderer for the Web content, used by Servo.
Note that the canonical home for this code is in gfx/wr folder of the mozilla-central repository at https://hg.mozilla.org/mozilla-central. The Github repository at https://github.com/servo/webrender should be considered a downstream mirror, although it contains additional metadata (such as Github wiki pages) that do not exist in mozilla-central. Pull requests against the Github repository are still being accepted, although once reviewed, they will be landed on mozilla-central first and then mirrored back. If you are familiar with the mozilla-central contribution workflow, filing bugs in Bugzilla and submitting patches there would be preferred.
Update as a Dependency
After updating shaders in WebRender, go to servo and:
- Go to the servo directory and do ./mach update-cargo -p webrender
- Create a pull request to servo
Use WebRender with Servo
To use a local copy of WebRender with servo, go to your servo build directory and:
- Edit Cargo.toml
- Add at the end of the file:
[patch."https://github.com/servo/webrender"]
"webrender" = { path = "<path>/webrender" }
"webrender_api" = { path = "<path>/webrender_api" }
where <path> is the path to your local copy of WebRender.
- Build as normal
Documentation
The Wiki has a few pages describing the internals and conventions of WebRender.
Testing
Tests run using OSMesa to get consistent rendering across platforms.
Still there may be differences depending on font libraries on your system, for example.
See this gist for how to make the text tests useful in Fedora, for example.