index.rst (3415B)
1 WebRender Tests 2 =============== 3 4 The WebRender class of tests are used to test the WebRender module 5 (lives in gfx/wr) in a standalone way, without being pulled into Gecko. 6 WebRender is written entirely in Rust code, and has its own test suites. 7 8 If you are having trouble with these test suites, please contact the 9 Graphics team (#gfx on Matrix/Element or Slack) and they will be able to 10 point you in the right direction. Bugs against these test suites should 11 be filed in the `Core :: Graphics: WebRender`__ component. 12 13 __ https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A%20WebRender 14 15 WebRender 16 --------- 17 18 The WebRender suite has one linting job, ``WR(tidy)``, and a 19 ``WR(wrench)`` test job per platform. Generally these test jobs are only 20 run if code inside the ``gfx/wr`` subtree are touched, although they may 21 also run if upstream files they depend on (e.g. docker images) are 22 modified. 23 24 WR(tidy) 25 ~~~~~~~~ 26 27 The tidy lint job basically runs the ``servo-tidy`` tool on the code in 28 the ``gfx/wr`` subtree. This tool checks a number of code style and 29 licensing things, and is good at emitting useful error messages if it 30 encounters problems. To run this locally, you can do something like 31 this: 32 33 .. code:: shell 34 35 cd gfx/wr 36 pip install servo-tidy 37 servo-tidy 38 39 To run on tryserver, use ``./mach try fuzzy`` and select the 40 ``webrender-lint-tidy`` job. 41 42 WR(wrench) 43 ~~~~~~~~~~ 44 45 The exact commands run by this test job vary per-platform. Generally, 46 the commands do some subset of these things: 47 48 - build the different webrender crates with different features 49 enabled/disabled to make sure they build without errors 50 - run ``cargo test`` to run the built-in rust tests 51 - run the reftests to ensure that the rendering produced by WebRender 52 matches the expectations 53 - run the rawtests (scenarios hand-written in Rust code) to ensure the 54 behaviour exhibited by WebRender is correct 55 56 Running locally (Desktop platforms) 57 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 58 59 The test scripts can be found in the ``gfx/wr/ci-scripts/`` folder and 60 can be run directly from the ``gfx/wr`` folder if you have the 61 prerequisite tools (compilers, libraries, etc.) installed. If you build 62 mozilla-central you should already have these tools. On MacOS you may 63 need to do a ``brew install cmake pkg-config`` in order to get 64 additional dependencies needed for building osmesa-src. 65 66 .. code:: shell 67 68 cd gfx/wr 69 ci-scripts/linux-debug-tests.sh # use the script for your platform as needed 70 71 Note that when running these tests locally, you might get small 72 antialiasing differences in the reftests, depending on your local 73 freetype library. This may cause a few tests from the ``reftests/text`` 74 folder to fail. Usually as long as they fail the same before/after your 75 patch it shouldn't be a problem, but doing a try push will confirm that. 76 77 Running locally (Android emulator/device) 78 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 79 80 To run the wrench reftests locally on an Android platform, you have to 81 first build the wrench tool for Android, and then run the mozharness 82 script that will control the emulator/device, install the APK, and run 83 the reftests. Steps for doing this are documented in more detail in the 84 ``gfx/wr/wrench/android.txt`` file. 85 86 Running on tryserver 87 ^^^^^^^^^^^^^^^^^^^^ 88 89 To run on tryserver, use ``./mach try fuzzy`` and select the appropriate 90 ``webrender-<platform>-(release|debug)`` job.