Platform/GFX/Quantum Render: Difference between revisions

Platform/GFX/Quantum Render (view source)

Revision as of 21:38, 14 December 2016

583 bytes added , 14 December 2016

Reorganize the hacking section

Kats

Confirmed users

586

edits

@@ Line 33: / Line 33: @@
 Once you have the code, see the README.webrender file in the root directory for build instructions. This can also be seen online at https://hg.mozilla.org/projects/graphics/file/tip/README.webrender
-== Understanding the code ==
+== Hacking ==
-A good overview of WebRender and what it is can be found in [http://www.masonchang.com/blog/2016/7/18/a-short-walkthrough-of-webrender-2 this blog post].
+There are lots of places to help hack on Quantum Render. See the sections below for some info on where to get started.
+=== On WebRender ===
+A good overview of WebRender and what it is can be found in [http://www.masonchang.com/blog/2016/7/18/a-short-walkthrough-of-webrender-2 this blog post]. WebRender is developed as a standalone library in the [https://github.com/servo/webrender WebRender github repo]. Look through the issues list to find things to work on.
+=== On Gecko integration ===
 If you are familiar with the way Gecko normally works, the Quantum Render changes should be relatively straightforward. Instead of using a ClientLayerManager, we create a [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/wr/WebRenderLayerManager.cpp WebRenderLayerManager] instance. This layer manager creates its own layer instances, and when those layers have their Render() function called, they generate WebRender-specific commands. These commands are sent over the [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/ipc/PWebRenderBridge.ipdl PWebRenderBridge] IPDL channel, which is conceptually similar to PLayerTransaction in Gecko. The commands are received in [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/wr/WebRenderBridgeParent.cpp WebRenderBridgeParent] which interprets the messages, and talks to the core WebRender library using the API in [https://hg.mozilla.org/projects/graphics/file/tip/gfx/webrender_bindings/src/webrender.h webrender.h]. The API is implemented in the [https://hg.mozilla.org/projects/graphics/file/tip/gfx/webrender_bindings/src/bindings.rs webrender_bindings] crate, which is written in Rust.
+Look through [https://bugzilla.mozilla.org/buglist.cgi?component=Graphics%3A%20WebRender&product=Core&bug_status=__open__&list_id=13349798 open unassigned bugs] (with no open dependencies) in the WebRender bugzilla component to find things to work on.
+=== On reftests ===
+Many of the existing gecko reftests (over 13000 of them) are passing with Quantum Render. However, there are still around 700 failing reftests. These are listed in [https://docs.google.com/a/mozilla.com/spreadsheets/d/1DcqaMvt3I38HIl3-RDS_6aiX67nQWItNcwmVt5utbDk/edit?usp=sharing this Google sheet]. You're welcome to work on getting these passing - please follow the procedure below:
+* Identify a single reftest you wish to work on. Try to pick one that sounds unrelated to other reftests that people are working on, because often one patch will fix multiple related reftests.
+* File a bug for that reftest, and mark it as blocking {{bug|1322815}} (webrender-reftests).
+* Update the Google sheet with the bug number and your name.
+* Work on the fix. The best way to do this is to remove the fails-if or skip-if annotation in your local checkout and run the reftest. Debug and fix as needed. Note that you can likely work on the bug on Windows/OS X locally, but we only run the tests on Linux in automation. So for best results, prefer working on Linux locally when possible.
+* If you need to do try pushes, use syntax "try: -b do -p linux64-qr -u all[linux64-qr] -t none". You should do at least one try push after writing your fix to verify it works in automation, as well as to identify any other tests that are fixed by your patch. Make sure to update the annotations for all newly-passing tests as part of your final commit. Try not to introduce regressions, although breaking a small number of tests to make a larger number pass might be acceptable.
+* Land your fix with pre- or post-review as appropriate.
 == Committing changes ==
@@ Line 90: / Line 108: @@
 The graphics branch currently runs all the usual tests (i.e. jobs that are run on mozilla-central) on each push. In addition, it also runs some new jobs specific to the Quantum Render code. Specifically, it runs 64-bit build jobs with --enable-webrender set, for Linux, OS X, and Windows. Both debug and opt builds are created. These can be seen on the [https://treeherder.mozilla.org/#/jobs?repo=graphics graphics TreeHerder page] in their own rows labelled with "qr" or "QuantumRender". The Linux QR builds also runs some reftest jobs - see the next section for details on this.
-=== Reftests ===
-Many of the existing gecko reftests (over 13000 of them) are passing with Quantum Render. However, there are still around 700 failing reftests. These are listed in [https://docs.google.com/a/mozilla.com/spreadsheets/d/1DcqaMvt3I38HIl3-RDS_6aiX67nQWItNcwmVt5utbDk/edit?usp=sharing this Google sheet]. You're welcome to work on getting these passing - please follow the procedure below:
-* Identify a single reftest you wish to work on. Try to pick one that sounds unrelated to other reftests that people are working on, because often one patch will fix multiple related reftests.
-* File a bug for that reftest, and mark it as blocking {{bug|1322815}} (webrender-reftests).
-* Update the Google sheet with the bug number and your name.
-* Work on the fix. The best way to do this is to remove the fails-if or skip-if annotation in your local checkout and run the reftest. Debug and fix as needed. Note that you can likely work on the bug on Windows/OS X locally, but we only run the tests on Linux in automation. So for best results, prefer working on Linux locally when possible.
-* If you need to do try pushes, use syntax "try: -b do -p linux64-qr -u all[linux64-qr] -t none". You should do at least one try push after writing your fix to verify it works in automation, as well as to identify any other tests that are fixed by your patch. Make sure to update the annotations for all newly-passing tests as part of your final commit. Try not to introduce regressions, although breaking a small number of tests to make a larger number pass might be acceptable.
-* Land your fix with pre- or post-review as appropriate.
 == Further reading ==