gecko-dev/gfx/wr
Dzmitry Malyshau 681ee8a0d0 Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw
The gist of the problem I introduced with the framebuffer coordinate system is that we provided the window rect (effectively) twice:
  1. when computing the document rectangle (and Y-inverting it)
  2. when rendering

If between these points the window got resized (during scene building), we end up with our document aligned to bottom left corner.
The user expects content to still be aligned to the top left, so that's what is visible as a bug.

The change here switched scene building to only care about device coordinate space, restraining the framebuffer coordinates to be mostly
an implementation detail of the renderer/device (the way it was originally meant to be, when introduced). This way the current window size
is only considered once during rendering.

Differential Revision: https://phabricator.services.mozilla.com/D28731

--HG--
extra : moz-landing-system : lando
2019-04-25 13:02:47 +00:00
..
ci-scripts Bug 1532284 - Build wrench on Android. r=glandium 2019-03-08 00:37:46 +00:00
debugger Backed out 8 changesets (bug 1542826) for build bustages. CLOSED TREE 2019-04-23 23:14:06 +03:00
direct-composition Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw 2019-04-25 13:02:47 +00:00
examples Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw 2019-04-25 13:02:47 +00:00
webrender Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw 2019-04-25 13:02:47 +00:00
webrender_api Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw 2019-04-25 13:02:47 +00:00
webrender_build Bug 1527884 - Make webrender_build publishable. r=kvark 2019-02-19 16:06:01 +00:00
wr_malloc_size_of Bug 1527884 - Make wr_malloc_size_of publishable. r=kvark 2019-02-15 15:47:00 +00:00
wrench Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw 2019-04-25 13:02:47 +00:00
.gitignore
.taskcluster.yml Bug 1515348 - Update webrender to commit 75ab41278fe7e24c45b22fa1af6879801d6f8ebc (WR PR #3434). r=kats 2018-12-19 19:28:51 +00:00
appveyor.yml Bug 1514737 - Update webrender to commit 7f2d2ea79e65d49f0da2030e6033761c38c1e296 (WR PR #3408). r=kats 2018-12-17 14:10:46 +00:00
Cargo.lock Bug 1546371 - Switch render backend and API away from FramebufferPixel r=gw 2019-04-25 13:02:47 +00:00
Cargo.toml Bug 1529117 - Bump serde and serde_derive to branch from 1.0.88. r=jrmuizel 2019-04-04 15:41:57 +00:00
LICENSE
README.md Bug 1507522 - Add a note to the WebRender README about the new upstream. r=kvark 2019-01-10 14:14:00 +00:00
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.