Closed Bug 1146561 Opened 5 years ago Closed 5 years ago

Plugin on background tab of http://blogs.nvidia.com/blog/2015/03/17/pascal/ causes 30fps of composition

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla40
Tracking Status
firefox36 - wontfix
firefox37 + wontfix
firefox38 --- wontfix
firefox38.0.5 + wontfix
firefox39 + fixed
firefox40 + fixed

People

(Reporter: jrmuizel, Assigned: bugs)

References

()

Details

Attachments

(2 files)

No description provided.
The refresh driver is ticking
It looks like this is caused by the plugins
Summary: Background tab of http://blogs.nvidia.com/blog/2015/03/17/pascal/ causes 30fps of composition → Plugin on background tab of http://blogs.nvidia.com/blog/2015/03/17/pascal/ causes 30fps of composition
Hmm, disabling the vsync refresh driver on OS X doesn't seem to change the FPS according to layers.acceleration.draw-fps.
It looks like this is not in 36 and is in 37. Talking to mstange suggests that it might be bug 1092630
[Tracking Requested - why for this release]: It's not clear if this happens for all plugins or just on this page. If it's for all plugins, the painting of background tabs at a high rate will be very bad for battery life.
I tested this on some other pages with plugins and it didn't seem to show up there. So that's good news.
Maybe I'm not doing it right but I wasn't able to reproduce. Using an aurora build I loaded the URL page and clicked-to-play the big webcast plugin at the bottom of the main page area. Switched to a different tab and kept an eye on the FPS counter, which for me went down to ~3-4. Based on the bug description I was expecting it to stay at around 30. Can you clarify STR?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7)
> Maybe I'm not doing it right but I wasn't able to reproduce. Using an aurora
> build I loaded the URL page and clicked-to-play the big webcast plugin at
> the bottom of the main page area. Switched to a different tab and kept an
> eye on the FPS counter, which for me went down to ~3-4. Based on the bug
> description I was expecting it to stay at around 30. Can you clarify STR?

Try disabling click-to-play and not scrolling down to the plugin.
Thanks, I can repro with that.
This bug is an edge case that we should fix but that won't block the 37 release. I have marked 37 as wontfix.
Jeff, do you have plans to work on this during the 38 beta cycle? Thanks
Flags: needinfo?(jmuizelaar)
Not immediate ones. It would be good if we could get a regression window though.
Flags: needinfo?(jmuizelaar)
Florin, do you know if anyone can reproduce this? Thanks
Flags: needinfo?(florin.mezei)
I was able to reproduce this and I'm working on a regression window - I hope to get it to you tomorrow, as mozregression is having some issues and probably needs updating. The issue is also reproducing only with e10s off, and I got some conflicting results and need to follow up tomorrow. 

One thing I noticed is that the issue appears after I hover the "x" button in the tab with the URL... not sure if that means anything.
I managed to get a regression window today, and this issue is caused by bug 1121811.

Last good revision: 34e2d2bd7ec4 - 2015-01-22
First bad revision: a6bbabebed2f - 2015-01-23
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=34e2d2bd7ec4&tochange=a6bbabebed2f

Further bisection points to:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f7439bc62b8b&tochange=b5842b906435

Steps to reproduce the issue:
1. Disable e10s from the settings (in case of Nightly build).
2. Open about:config and set layers.acceleration.draw-fps=true.
3. In a new tab go to http://blogs.nvidia.com/blog/2015/03/17/pascal/.
4. After the page loads, hover the mouse over the "x" button of the tab with the nvidia URL -> you should see the counter going to ~30 FPS and sticking there.
5. Click on the first tab (about:config) or any other tab. 

Result: counter stays at 30 FPS instead of dropping to ~3-4 FPS. Note that at step 4, prior to the fix in 1121811, the counter never got up to stay at high values. The only issue was in e10s mode where the counter would get to 60 FPS and stay.
Blocks: 1121811
Flags: needinfo?(florin.mezei)
Thanks Florin, you rock!

David, can you help on this issue? Thanks
Flags: needinfo?(davidp99)
Unfortunately, I doubt I'd have time to look at this in the next few weeks.  Steven, got an idea on how to direct this?
Flags: needinfo?(davidp99) → needinfo?(smichaud)
Since Benoit Girard's patch seems to have triggered this bug, we should probably ask him :-)

But I notice from his "bugzilla name" that he's on leave til June 1st.

There probably isn't much I can do here -- at least not without a *lot* of work to familiarize myself with the code where this problem seems to be happening.  And I'm also very busy with other things.

I don't know who else to ask?  Jeff again?
Flags: needinfo?(smichaud)
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bgirard)
Milan, who is the "backup" of Benoit when he is off?
Flags: needinfo?(milan)
The culprit identified in comment 15 is bug 1121811, but that was just a backout of bug 1092630.  I'm including Josh in here as he originally authored the first one and reviewed the backout, but I think this may be just tickling a different underlying bug?

Also adding Jet in case he can think of somebody that knows this code well.
Flags: needinfo?(milan)
Flags: needinfo?(joshmoz)
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bugs)
Flags: needinfo?(bgirard)
The regressing patch replaced a call to CallSetWindow() that had a visibility check. This patch adds the missing visibility check before we enable painting for the plugin window.
Flags: needinfo?(joshmoz)
Flags: needinfo?(bugs)
Attachment #8597547 - Flags: review?(jmuizelaar)
Comment on attachment 8597547 [details] [diff] [review]
Adds back the visibility check for Mac plugins

Review of attachment 8597547 [details] [diff] [review]:
-----------------------------------------------------------------

This seems reasonable to me.
Attachment #8597547 - Flags: review?(jmuizelaar) → review+
https://hg.mozilla.org/mozilla-central/rev/ff5588b74fa4
Assignee: nobody → bugs
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Jet, this is too late for 38 but we could take a patch for 38.0.5 as it seems safe.
Could you fill the uplift request? Thanks
Flags: qe-verify+
[Tracking Requested - why for this release]:

Approval Request Comment
[Feature/regressing bug #]: bug 1121811
[User impact if declined]: Power & Performance regression
[Describe test coverage new/current, TreeHerder]: CI + Manual testing verification. Has been on central for a few days now.
[Risks and why]: Low. Adds a missing visibility check needed to suppress invalidation/paint.
[String/UUID change made/needed]: None
Flags: needinfo?(bugs)
Comment on attachment 8597547 [details] [diff] [review]
Adds back the visibility check for Mac plugins

Setting the correct flags (see the previous comment)
Attachment #8597547 - Flags: approval-mozilla-beta?
Attachment #8597547 - Flags: approval-mozilla-aurora?
Comment on attachment 8597547 [details] [diff] [review]
Adds back the visibility check for Mac plugins

Too late for 38 but taking it for 39.
Attachment #8597547 - Flags: approval-mozilla-beta?
Attachment #8597547 - Flags: approval-mozilla-beta-
Attachment #8597547 - Flags: approval-mozilla-aurora?
Attachment #8597547 - Flags: approval-mozilla-aurora+
I've tested this today using scenario from comment 15, on Mac OS X 10.8.5, with latest Firefox 41 Nightly (BuildID=20150513030209) and latest Firefox 39 Aurora (BuildID=20150511004005). 

I still see the same behavior as before: 
- load http://blogs.nvidia.com/blog/2015/03/17/pascal/ and hover the tab's "x" button ---> the first two counters go to ~30 and stay there 
- click on another tab ---> the second counter goes down to ~1-2, but the first counter stays at ~30

I was under the impression that both counters should go down when switching to another tab... Jet or Jeff, can you please provide your thoughts on this?
(In reply to Florin Mezei, QA (:FlorinMezei) [PTO - May 18-29] from comment #30)
> I've tested this today using scenario from comment 15, on Mac OS X 10.8.5,
> with latest Firefox 41 Nightly (BuildID=20150513030209) and latest Firefox
> 39 Aurora (BuildID=20150511004005). 
> 
> I still see the same behavior as before: 
> - load http://blogs.nvidia.com/blog/2015/03/17/pascal/ and hover the tab's
> "x" button ---> the first two counters go to ~30 and stay there 
> - click on another tab ---> the second counter goes down to ~1-2, but the
> first counter stays at ~30
> 
> I was under the impression that both counters should go down when switching
> to another tab... Jet or Jeff, can you please provide your thoughts on this?

Jet, Jeff - any updates on this?
Flags: needinfo?(bugs)
(In reply to Andrei Vaida, QA [:avaida] from comment #31)
> (In reply to Florin Mezei, QA (:FlorinMezei) [PTO - May 18-29] from comment
> #30)
> > I've tested this today using scenario from comment 15, on Mac OS X 10.8.5,
> > with latest Firefox 41 Nightly (BuildID=20150513030209) and latest Firefox
> > 39 Aurora (BuildID=20150511004005). 
> > 
> > I still see the same behavior as before: 
> > - load http://blogs.nvidia.com/blog/2015/03/17/pascal/ and hover the tab's
> > "x" button ---> the first two counters go to ~30 and stay there 
> > - click on another tab ---> the second counter goes down to ~1-2, but the
> > first counter stays at ~30
> > 
> > I was under the impression that both counters should go down when switching
> > to another tab... Jet or Jeff, can you please provide your thoughts on this?
> 
> Jet, Jeff - any updates on this?

I'm not seeing that on my Mac (OSX 10.10) Both the first (composites) and second (transactions) FPS counters go down to ~2fps. The page tabbed to may be a factor here and may actually have a valid reason for compositing at 30fps. Please test with just two tabs and report back:

1. http://blogs.nvidia.com/blog/2015/03/17/pascal/
2. about:blank
Flags: needinfo?(bugs)
(In reply to Jet Villegas (:jet) from comment #32)
> I'm not seeing that on my Mac (OSX 10.10) Both the first (composites) and
> second (transactions) FPS counters go down to ~2fps. The page tabbed to may
> be a factor here and may actually have a valid reason for compositing at
> 30fps. Please test with just two tabs and report back:
> 
> 1. http://blogs.nvidia.com/blog/2015/03/17/pascal/
> 2. about:blank

Sorry for the late response, but I was away for 2 weeks and only now got the chance to get back to this.

I've re-tested this today with only the two tabs as suggested above. I tested on Mac OS X 10.8.5 and 10.10, using the latest Firefox 40 Aurora and Firefox 41 Nightly. 

I now see both counters staying at ~30 fps after clicking on the about:blank tab. I basically used the steps from comment 15, but with only the two tabs specified above. The issue still reproduces for me.
Jet, any thoughts on the results above in comment 33?
Flags: needinfo?(bugs)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #34)
> Jet, any thoughts on the results above in comment 33?

I may be missing a key step in my testing, which I posted as video here:
http://media.junglecode.net/test/1146561/test.html
Flags: needinfo?(bugs)
Attached video Fx_39b6.m4v
(In reply to Jet Villegas (:jet) from comment #35)
> I may be missing a key step in my testing, which I posted as video here:
> http://media.junglecode.net/test/1146561/test.html

One key step that you may be missing is disabling e10s. The issue only shows when multi process is disabled. Otherwise you seem to be doing the same things that I'm doing.

See attached a short video of how I reproduced this today with Firefox 39 Beta 6 on Mac OS X 10.8.5.
I also have the latest Flash version - 18.0.0.160.
Jet, any success reproducing this?
Flags: needinfo?(bugs)
I'm unable to reproduce with or without e10s. I'm running NPAPI Plug-in version 18.0.0.203 on OSX 10.10, in case that matters.
Flags: needinfo?(bugs)
I tried today the scenario from comment 33 on 3 different machines, with Firefox 40 beta 4 (latest Beta available) and I could easily reproduce the issue of counters staying at ~30 on all 3 machines. Flash 18.0.0.209 was running on all 3 machines.

Test machines info:
- Mac mini - mid 2011 - OS X 10.8.5, OS X 10.9.5
- iMac - Late 2012 - OS X 10.10.4
- Macbook Pro retina 15" - Late 2013 - OS X 10.9.5

At this point all I can think about is that there may be something on your machine that no longer reproduces this... if you have any other ideas on things to try on my side I'm open to them, otherwise I think there's nothing more for me to do for this issue. 

Should I reopen this or do something to track the issue that I'm still seeing?
Flags: needinfo?(bugs)
Removing qe-verify+ flag since this was tested and it's importance has diminished.
Flags: qe-verify+
Benoit: I landed this fix while you were out and it appears to fix the issue on my computers. Can you have a look to see if you can reproduce? If so, can you review my fix to see why? Thanks!
Flags: needinfo?(bugs) → needinfo?(bgirard)
I get 30 FPS on that tab but 0 FPS when it's in the background. Looks good, thank you Jet!
Status: RESOLVED → VERIFIED
Flags: needinfo?(bgirard)
You need to log in before you can comment on or make changes to this bug.