4d7909d785
Allow the swizzle to be configurable with a texture binding. This is still experimental and needs to be tested well on all platforms. Basic approach is the following: - WR device figures out how it can use BGRA and makes the texture cache format configurable at run-time. It tries to make the uploads to the shared texture cache pages to be done without any driver conversions, and without extra memory allocated. - it also reports the preferred input format for the images, which may be different from the texture cache format - if WR texture cache is asked to allocate a shared texture with a different (swizzled) format from the preferred, it associates the cache entry with a swizzle - the swizzle becomes a part of the `SourceTexture`, which affects batch splitting - when a texture reaches binding by GL device, it checks whether the current swizzle on this texture doesn't match the given one, and configures the texture sampling accordingly - we can't use blits with swizzling, so when that needs to happen we use `cs_copy` path, which is now mostly rewritten The idea is that Gecko would ask WR for the preferred format and configure its image decoding to produce image data that doesn't require any swizzling. The PR changes existing texture upload (and batching) paths. On Linux, if texture storage is available, we now use it and provide the data as RGBA, assuming no conversion by the driver. The swizzling kicks in when we sample this data in the shader. On Windows/Angle we use BGRA as an internal format for texture cache and expect Gecko to provide BGRA data, this should be unchanged. Differential Revision: https://phabricator.services.mozilla.com/D21965 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| ci-scripts | ||
| debugger | ||
| direct-composition | ||
| examples | ||
| peek-poke | ||
| 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.