This bug try to update webrender to ee97fcaa. The new version of webrender starts to use z-buffer, but gecko doesn't create a gl context with z-buffer. I will have a patch to do this. Here is the current try result with z-buffer enabled gl context. https://treeherder.mozilla.org/#/jobs?repo=try&revision=20553813ed9de563d13652590164c04743329af0&selectedJob=67123698 We still have some failed tests, but the number is not to much. So, I will try do disable these tests first.

WebRender starts to use depth-buffer, but the default FBConfig doesn't have that. This patch try to choose a compatible(same color bits) FBConfig with depth setting. MozReview-Commit-ID: HgAEshdNsFs

MozReview-Commit-ID: J1xT0xDI715

(In reply to Jerry Shih[:jerry] (UTC+8) from comment #0) > Here is the current try result with z-buffer enabled gl context. > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=20553813ed9de563d13652590164c04743329af0&selectedJob=6 > 7123698 > > We still have some failed tests, but the number is not to much. > So, I will try do disable these tests first. Some of these failures look really odd, like the R1 debug failures. There's just a big black square in the bottom-left corner for no apparent reason. I'd like to find out which changes introduced these failures before we decide whether or not to disable them.

Comment on attachment 8824902 [details] [diff] [review] enable depth-buffer for CGL gl context. Review of attachment 8824902 [details] [diff] [review]: ----------------------------------------------------------------- Also please investigate the reftest failures before disabling them. ::: gfx/gl/GLContextProviderCGL.mm @@ +202,5 @@ > NSOpenGLPFAAllowOfflineRenderers, > NSOpenGLPFADoubleBuffer, > NSOpenGLPFAOpenGLProfile, > NSOpenGLProfileVersion3_2Core, > + NSOpenGLPFADepthSize, 24, I saw that this is the same as WR, but it'd be nice if there was a comment here linking to that or keep it in sync with WR.

Don't we need one for WGL context on windows as well? I'm not sure this is the right place, but maybe? [1] [1] http://searchfox.org/mozilla-central/source/gfx/gl/GLContextProviderWGL.cpp#69

Here is the rebased try link: Let me debug for the black rect at bottom-left. https://treeherder.mozilla.org/#/jobs?repo=try&revision=1fa5ed17d6257aad3684d45712dde3fb9b97076c

I try to create a gl context with z-buffer for WR. Do the settings in this CreateDummyWindow() affect the gl context used by WR? https://dxr.mozilla.org/mozilla-central/rev/d192a99be4b436f2dc839435319f7630d5d8f4b0/gfx/gl/GLContextProviderWGL.cpp#136 We create the gl context through https://dxr.mozilla.org/mozilla-central/rev/d192a99be4b436f2dc839435319f7630d5d8f4b0/gfx/gl/GLContextProviderWGL.cpp#437 https://dxr.mozilla.org/mozilla-central/rev/d192a99be4b436f2dc839435319f7630d5d8f4b0/gfx/gl/GLContextProviderWGL.cpp#443

It's kind of weird that the opt builds are mostly passing and the debug builds have a bunch of failures. Makes me suspect we're not initializing things properly somewhere.

Comment on attachment 8824901 [details] [diff] [review] enable depth-buffer for GLX gl context. Lee is a better reviewer for this.

Comment on attachment 8825133 [details] [diff] [review] enable depth-buffer for WGL gl context. Review of attachment 8825133 [details] [diff] [review]: ----------------------------------------------------------------- Forwarding this to Jeff, if we don't use this anywhere right now I'm fine with this change.

Comment on attachment 8825133 [details] [diff] [review] enable depth-buffer for WGL gl context. Review of attachment 8825133 [details] [diff] [review]: ----------------------------------------------------------------- I forgot to add the "gfxPrefs::WebRenderEnabled()" condition for this z-buffer configuration. If this patch looks good, I will add an gfxPrefs::WebRenderEnabled() condition around this new configuration.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > It's kind of weird that the opt builds are mostly passing and the debug > builds have a bunch of failures. Makes me suspect we're not initializing > things properly somewhere. Another interesting thing is that, failed tests are all the first test in chunks. I still can't reproduce this weird result locally with my linux and mac laptop. I will try to test again on VM or the actual try server VM.

The latest tree: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d72fd08925a125dc5a36593423b377e4b0106b7&selectedJob=67899101

When I create gl context with z-buffer and double-buffer, the failed tests in https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d72fd08925a125dc5a36593423b377e4b0106b7&selectedJob=67899101 are passed. Here is the latest try with z-buffer and double-buffer. If it looks good, I will push them to our branch. https://treeherder.mozilla.org/#/jobs?repo=try&revision=1eca32b6dca1a1c16f36d3ae530a06f634bb096a

All linux tests are passed in https://treeherder.mozilla.org/#/jobs?repo=try&revision=1eca32b6dca1a1c16f36d3ae530a06f634bb096a , but the build at osx are broken. I don't have the idea about this problem right now. I can find the symbol in my local build(I use |nm| to check the symbol list in libgkrust_gtest.a). [task 2017-01-13T11:10:08.881844Z] 11:10:08 INFO - Undefined symbols for architecture x86_64: [task 2017-01-13T11:10:08.882039Z] 11:10:08 INFO - "_CGEventPostToPid", referenced from: [task 2017-01-13T11:10:08.882265Z] 11:10:08 INFO - core_graphics::event::CGEvent::post_to_pid::h69c3f43f7c4465c1 in libgkrust_gtest.a(core_graphics-cb2fdde346490591.0.o) I push this change into graphic branch first, since someone needs the new WR changes. Then, I will still try to figure out the build break reason.

Pushed by hshih@mozilla.com: https://hg.mozilla.org/projects/graphics/rev/76ee21f3118f update WR to ee97fcaa4ee8eda89f7bd67b1a8920d3382af294. r=kats? https://hg.mozilla.org/projects/graphics/rev/1351dcac4ed6 |mach vendor rust| updates for WR ee97fcaa. r=kats? https://hg.mozilla.org/projects/graphics/rev/dc699e349388 update webrender_bindings for Renderer options changes. r=gfx? https://hg.mozilla.org/projects/graphics/rev/2821fbacad22 update WR binding for external image life-time updates. r=nical? https://hg.mozilla.org/projects/graphics/rev/5e76e3fb4563 enable depth-buffer for CGL gl context. r=mchang https://hg.mozilla.org/projects/graphics/rev/7cbd063bab4e enable depth-buffer for GLX gl context. r=lsalzman https://hg.mozilla.org/projects/graphics/rev/2392f43279a5 try to create double-buffer for GLX gl context. r=jrmuizel? https://hg.mozilla.org/projects/graphics/rev/648d37cd4daa enable depth-buffer for WGL gl context. r=jgilbert

Thanks to :nical ! The build break comes from: https://hg.mozilla.org/try/rev/76f86442482a4e7dd74a8e29fd51075d5871ccb1#l25.211 The new version of core-graphics 0.4.3 uses a new api CGEventPostToPid() with is macOS 10.11+. I try to fix the core-graphics version as: webrender/Cargo.toml core-graphics = "0.4.1" webrender_traits/Cargo.toml core-graphics = "0.4.1" But after I follow the instructions in README.webrender, there is still having a 0.4.3 core-graphics in third_party library. :kats , should we use "cargo update --aggressive -p webrender" to get the latest vesion?

This is the 10.7 build break issue to core-graphics. https://github.com/servo/core-graphics-rs/issues/66

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/projects/graphics/rev/a86045a89b11 Follow-up to remove leftover files from webrender update. r=hshih? https://hg.mozilla.org/projects/graphics/rev/d721e1ac457f Downgrade core-graphics from 0.4.3 to 0.4.1. r=gfx? https://hg.mozilla.org/projects/graphics/rev/aa19a56f87c8 Re-run mach vendor rust to pick up the core-graphics downgrade. Also picks up a missing error-chain file. r=gfx?

(In reply to Jerry Shih[:jerry] (UTC+8) from comment #18) > But after I follow the instructions in README.webrender, there is still > having a 0.4.3 core-graphics in third_party library. > > :kats , should we use "cargo update --aggressive -p webrender" to get the > latest vesion? In general, yes. However in cases where it updates "too aggressively" and you need to downgrade a package, you can use |cargo update -p <package> --precise <version>|. That's what I did in the follow-up patches in comment 20. I also added this to the README.webrender in case it happens again. More info in the mailing-list reply at https://groups.google.com/d/msg/mozilla.dev.tech.gfx/t59TTiyWUqk/TiBw47UZEwAJ

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/projects/graphics/rev/f11c9a6770b4 core-graphics 0.4.3 is Too New, 0.4.1 is Too Old, but 0.4.2 is Just Right. r=gfx? https://hg.mozilla.org/projects/graphics/rev/2dad5748892e Re-run mach vendor rust to pick up core-graphics 0.4.2. r=gfx?