Version: 63.0a1 Build: ID 20180709221247 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 [Affected Platforms]: - Windows 10 64bit [Steps to reproduce]: 1. Open Firefox Nightly (63.0a1) with a new profile and navigate to http://arodic.github.io/p/jellyfish/ 2. Observe the fps value from the top left corner of the website. 3. Go to about:config and add "gfx.webrender.all.qualified" preference with true value 4. Restart the browser. 5. Navigate to http://arodic.github.io/p/jellyfish/ 6. Observe the fps value from the top left corner of the website. [Expected result]: - Fps value is equal or higher with WebRender enabled. [Actual result]: - Fps value is on average with 30% lower with WebRender enabled. [Notes]: - This issue is only reproducible with webgl demo websites. - On https://youtube.com and https://twitch.tv fps value with WebRender is higher. - Attached a link to fps test results: https://tinyurl.com/yao275le. - Attached a copy of about:support from both systems this issue was tested on. - Attached a screen recording of the issue: https://tinyurl.com/y9d79u69.

> 5. Navigate to http://arodic.github.io/p/jellyfish/ Debian Testing, GTX 1060, 2560x1440, 20180710100040 gfx.webrender.debug.profiler shows me 89-114 FPS. (Does it need to be that high on a 60Hz screen?)

Profile: https://perfht.ml/2JbQCnA Seems like we're blocking in SwapBuffers a lot

This looks similar to Bug 1470327. In both cases, Renderer::render_impl() was always called twice for each frame render. One was called in Renderer::update() another was called in Renderer::render(). Then when I enabled profiler of webrender, it shows 120fps because fps was doubled by 2 render_impl() calls. WebRenderBridgeParent::CompositeToTarget() actually requested 60fps composite.

During the `update()` we only try to fill the texture cache: // If the document we are replacing must be drawn // (in order to update the texture cache), issue // a render just to off-screen targets. if self.active_documents[pos].1.frame.must_be_drawn() { self.render_impl(None).ok(); } So the idea is - any subsequent renders would just re-use the texture cache items rendered here, so no work is wasted. We need to double-check if this is actually happening though.

On Windows 10 (GTX 1060 3GB) FPS numbers were as expected (25 & 60fps), except for "jellyfish" which itself said it had 60 fps, but the profiler showed ~120fps. comment 0's GeForce 210: http://gpuboss.com/gpus/GeForce-GTX-1060-Fake-Card-vs-GeForce-210-PCI https://www.geforce.com/hardware/desktop-gpus/geforce-210/specifications

From https://github.com/servo/webrender/issues/2887, very high fps is different problem than the performance.

I tested the first 5 URLs from the spreadsheet (all the non-youtube ones) on my machine, I was consistently getting 60fps with WR. I was also getting 60fps without WR, except for http://alteredqualia.com/three/examples/webgl_pasta.html where it was closer to 35. So basically I can't reproduce the issue as stated in comment 0. Can anybody else?

Note also the 5 URLs all display their own FPS counters, so they are probably reporting requestAnimationFrame counts and have nothing to do with the render_impl business.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7) > I tested the first 5 URLs from the spreadsheet (all the non-youtube ones) on > my machine, I was consistently getting 60fps with WR. I was also getting > 60fps without WR, except for > http://alteredqualia.com/three/examples/webgl_pasta.html where it was closer > to 35. So basically I can't reproduce the issue as stated in comment 0. Can > anybody else? I could reproduce the issue of comment 0 on my Win10 laptop(P50). Current FPS counter of webrender profile is broken. With https://github.com/servo/webrender/pull/2889, the fps of the webrender profiler became 30fps.Without webrender, fps was 45-50 fps.

By the way, WebGL performance in general might becomes better with bug 1475010.

(In reply to Sotaro Ikeda [:sotaro] from comment #9) > I could reproduce the issue of comment 0 on my Win10 laptop(P50). Current > FPS counter of webrender profile is broken. With > https://github.com/servo/webrender/pull/2889, the fps of the webrender > profiler became 30fps.Without webrender, fps was 45-50 fps. Yeah, but the reporter wasn't using the webrender profiler FPS counter. The one that matters for this bug is the FPS counter that the page is displaying by itself. Can you attach a gecko profile with the WR threads of one of these pages with low FPS?

The followings are gecko profile on Win10 laptop(P50) With WebRender https://perfht.ml/2uwPi9t Without WebRender https://perfht.ml/2uvgBkC

I also started a build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=bca74247685d9e2d92d280c456f88ecb4de7b3f3 with the keyed mutex fix from bug 1475010 to see if that helps.

(In reply to Sotaro Ikeda [:sotaro] from comment #12) > The followings are gecko profile on Win10 laptop(P50) > > With WebRender > https://perfht.ml/2uwPi9t > Without WebRender > https://perfht.ml/2uvgBkC Finer profile sample of Without WebRender. Compositor thread seemed not busy. https://perfht.ml/2zAUwa0

The build in comment 13 is done now, could you check if you still see the problem on that build?

Hi, we already tested the build in comment 13. There is a slight improvement with it, but not really a big difference. Here you can see the test results: https://tinyurl.com/yb5n8gkw.

Thanks, from the number it seems like the jellyfish demo (which was the one that was worst with WR compared to non-WR) is improved the most with the try build, which is good.

Not looking at it right now, de-assigning.

We can't release this to the field, but we can let this ride to beta.

Sotaro, can you still reproduce an issue here? I get 60fps on the Jellyfish demo, with really low CPU usage.

(In reply to Matt Woodrow (:mattwoodrow) from comment #20) > Sotaro, can you still reproduce an issue here? > > I get 60fps on the Jellyfish demo, with really low CPU usage. Yes, I got 30fps on Win10 P50 laptop(Intel(R) HD Graphics P530). CPU usage is still low. But wait happened at RenderCompositorANGLE::WaitForPreviousPresentQuery(). Wit triple buffer of Bug 150001, the problem was addressed.

(In reply to Sotaro Ikeda [:sotaro] from comment #21) > (In reply to Matt Woodrow (:mattwoodrow) from comment #20) > RenderCompositorANGLE::WaitForPreviousPresentQuery(). Wit triple buffer of > Bug 150001, the problem was addressed. Correction: With triple buffer of Bug 1500017, the problem was addressed.

:acupsa, can you check the problem again? Bug 1500017 was addressed and it addressed the problem for me.

Close this bug, Bug 1500017 addressed problem for me on Win10 P50 laptop(Intel(R) HD Graphics P530).