diff --git a/gfx/webrender_bindings/README.webrender b/gfx/webrender_bindings/README.webrender index 69f59d172229..a78371e5375d 100644 --- a/gfx/webrender_bindings/README.webrender +++ b/gfx/webrender_bindings/README.webrender @@ -22,153 +22,3 @@ For a debug webrender build: Use a debug mozconfig (ac_add_options --enable-debug) You can also use an opt build but make webrender less optimized by putting opt-level=0 in the [profile.release] section of your toolkit/library/rust/Cargo.toml file See also https://groups.google.com/forum/#!topic/mozilla.dev.servo/MbeMcqqO1fs - --------------------------------------------------------------------------------- - -What if you have to pull in an update to webrender itself? You have two options, -listed below. Both options will give you a set of patches and the ability to do -try pushes to verify the update. After that, continue with the steps below to -actually land the update into the tree. - -Option A: - Use a script to do the update for you. This will usually work, if you satisfy - all the assumptions the script is making. The script can be found at - https://github.com/staktrace/wrupdater/blob/master/try-latest-webrender.sh - and contains documentation on how to use it. Read the documentation carefully - before trying to use it. - -Option B: - Do the update manually. This is a little more cumbersome but may be required - if the script doesn't work or the repos are in a state that violates hidden - assumptions in the script (e.g. if the webrender_bindings/Cargo.toml file is - no longer in the format expected by the script). The steps to do this are, - roughly: - - Update your mozilla-central checkout to the latest code on mozilla-central. - - Check out and update the webrender repo to the version you want - - Copy over the webrender repo to gfx/wr. The easiest way to do this is - simply delete gfx/wr, and use |cp -R| to copy it back, and then delete the - gfx/wr/.git/ subfolder. Update the revision in - gfx/webrender_bindings/revision.txt file with the git changeset hash. - - If you need to modify webrender_bindings/Cargo.toml file, do so now. Changes - at this step usually consist of: - (a) Updating version numbers. Go through the version numbers of ALL the - dependencies in the Cargo.toml file (webrender, euclid, etc.) and make - sure the version numbers listed match what's in the new - gfx/wr/webrender/Cargo.toml and gfx/wr/webrender_api/Cargo.toml files. - (b) Turning on or off any new features that were added in upstream WR. This - used to happen a lot but is pretty rare now. - - Go to toolkit/library/rust and run |cargo update -p webrender -p webrender_api|. - If it complains about version numbers of other crates not lining up, add those - as well, e.g. |cargo update -p webrender -p webrender_api -p gleam -p euclid|. - You may need to do this a few times until you get all the crates to make it - happy. - - Run the same cargo update command from the previous step in the - toolkit/library/gtest/rust folder. - - Commit your changes locally. You'll need to do this before the next step or - it will complain. - - At the top of the tree, run |mach vendor rust| to update the rust - dependencies in third_party/rust. - - Commit your changes locally. - - Build and test. You may need to make changes in bindings.rs or on the C++ - side depending on what changed in webrender. This can potentially be quite - tricky if you don't fully understand the API changes on the webrender side. - Get help if you need it. For simplicity in bisecting, try to not use your - new features yet, just get the build working with the minimal changes. - - Commit any changes from the previous step, and do a try push to make sure - everything is good. Generally we do two try pushes, one for builds and - linux tests. This should be totally green. The other forces WR enabled on - Windows and runs reftests, which currently fails. However if it fails with - more than just regular reftest failures (e.g. it crashes or has an assertion - failure) then that's potentially going to be a problem for Windows users - running WebRender and will need investigation. - - You now have an updated webrender, so you can land it or write gecko - code against the new features. - -Once you have followed either Option A or Option B and have a good update, you -might want to land it in the tree. To do this: -- Find the current wr-future-update bug, by going to https://bugzil.la/wr-future-update -- Clone this bug (there is a little dropdown in the bottom right corner of the - page which gives you an option to "Create a new bug ... as a clone of this bug"). -- This will take you to a bug entry page with some stuff prepopulated. Do NOT - submit it yet, but make the following changes: - (a) Modify the "Description" to remove the SECOND instance of the text "+++ This - bug was initially created as a clone of ... +++". Keep the first instance - as it points to the bug you just cloned, and keep the rest of the text unless - you feel it needs changing. - (b) Add wr-future-update into the "Alias" field - (c) Clear the bugs in the "Depends on" field - (d) For each bug in the "Blocks" field, except for 1311790 and 1386670, go - to the bug and check the "See Also" link for the corresponding WR issue/PR, - if any. If there is a WR issue that is not yet resolved in the update you - are landing, leave the bug in the "Blocks" field of your clone. In a later - step you will remove the dependency from the update you are landing. At - end of this step the "Blocks" field should contain 1311790, 1386670, and - any bugs tracking upstream WR issues that are not fixed in the update. - (e) You still cannot submit the clone as a new bug, because you can't have two - bugs in the system with the same alias. So hold on a sec. -- Go back to the tab with the current wr-future-update bug, and click on the edit - button. Make the following changes: - (a) Assign the bug to yourself. - (b) Clear the "Alias" field. - (c) Remove bugs from the "Blocks" field that you kept in step (d), other than - 1311790 and 1386670. In other words, update the "Blocks" field so that it - contains 1311790, 1386670, and any bugs that are actually fixed by the - update. - (d) Submit your changes to this bug. -- Now you can submit your changes to the clone bug which will create a new - wr-future-update bug. -- Update your patch queue so that the patches are properly formatted with - bug number, reviewer, etc. and push to MozReview. This is kind of important, - because you want these patches to land on autoland rather than inbound. If it - lands on inbound there's a high chance of it conflicting with the servo-vcs-sync - bot that is regularly pushing to autoland, and then you'll only find out about - it when the sheriff tries to do a merge and backs you out. If you push to - autoland you're likely to find out about the problem at push time, when the - patches won't rebase. - - -Troubleshooting tips: - -1. Note that when webrender is built as part of gecko, it may end up using slightly - different versions of its dependencies than when it is built standalone from the - webrender repo. The reason is that the Cargo.lock files in m-c and in the WR - repo may reference different versions of the dependencies. Both builds will be - compatible in terms of semantic versioning, but may produce different results - - for example the standalone webrender might use euclid 0.10.4 while the - one in gecko uses euclid 0.10.3. Although both choices are "valid" per - the semantic versioning rules in webrender's Cargo.toml, the 0.2.3 may provide - a bugfix that is needed for correct behaviour in webrender. If this is the case, - the technically "correct" fix is to change the upstream webrender Cargo.toml - file to require the correct version. Alternnatively, you can update the - Cargo.lock files in m-c to pull in the new version. The way to do this is as - follows: - - Go to toolkit/library/rust and run |cargo update -p --precise |. - Repeat this for as many libraries as you need to update. Run the same commands - in toolkit/library/gtest/rust and js/src (ignore any errors about unmatched - packages). Commit all the changes locally. - - Run |mach vendor rust|, which will update the corresponding libraries in - third_party/rust to the versions you specified. - The reason we don't do this by default is to work around bug 1336528. Specifically, - there is another crate in m-c called mozjs_sys which is built separately but uses - the same folder to store its rust dependencies. If one of the libraries that is - required by both mozjs_sys and webrender is updated without updating the other - project's Cargo.lock file, that results in build bustage. - This means that any time you do this sort of manual update of packages, you need - to make sure that mozjs_sys also has its Cargo.lock file updated if needed, hence - the need to run the cargo update command in js/src as well. Hopefully this will - be resolved soon. - -2. Sometimes autoland tip has changed enough from mozilla-central (because of the - servo vcs-sync-bot, which will sync servo into m-c and often re-vendor third- - party rust dependencies) that trying to land an update based on mozilla-central - will not work well. As in, you'll get conflicts in Cargo.lock files or in the - third_party/rust directory. This is best handled by running your update steps - on top of autoland tip rather than central. (The script-based update in option A - has an env var you can set to do this). In theory you can get the same - result by resolving the conflict manually but Cargo.lock files are usually not - trivial to merge by hand. If it's just the third_party/rust dir that has conflicts - you can delete it and run |mach vendor rust| again to repopulate it. - -------------------------------------------------------------------------------- - -The current WebRender revision can be found in gfx/webrender_bindings/revision.txt file. diff --git a/gfx/webrender_bindings/revision.txt b/gfx/webrender_bindings/revision.txt deleted file mode 100644 index 063401722408..000000000000 --- a/gfx/webrender_bindings/revision.txt +++ /dev/null @@ -1 +0,0 @@ -d3edc30cf95d3c96fd8308969b22062698a0f6ce diff --git a/gfx/webrender_bindings/src/bindings.rs b/gfx/webrender_bindings/src/bindings.rs index 4e4a3226d125..a14f579aa86c 100644 --- a/gfx/webrender_bindings/src/bindings.rs +++ b/gfx/webrender_bindings/src/bindings.rs @@ -1699,8 +1699,6 @@ pub extern "C" fn wr_api_capture( let _ = create_dir_all(&path); match File::create(path.join("wr.txt")) { Ok(mut file) => { - let revision = include_bytes!("../revision.txt"); - file.write(revision).unwrap(); // The Gecko HG revision is available at compile time if let Some(moz_revision) = option_env!("GECKO_HEAD_REV") { writeln!(file, "mozilla-central {}", moz_revision).unwrap();