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

Status: VERIFIED FIXED

(Core :: Layout, defect)

Comment 1

[Jeff Muizelaar [:jrmuizel]]

The refresh driver is ticking

Comment 2

[Jeff Muizelaar [:jrmuizel]]

It looks like this is caused by the plugins

Comment 3

[Mason Chang [Inactive] [:mchang]]

Hmm, disabling the vsync refresh driver on OS X doesn't seem to change the FPS according to layers.acceleration.draw-fps.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

It looks like this is not in 36 and is in 37. Talking to mstange suggests that it might be bug 1092630

Comment 5

[Jeff Muizelaar [:jrmuizel]]

[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.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

I tested this on some other pages with plugins and it didn't seem to show up there. So that's good news.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 8

[Jeff Muizelaar [:jrmuizel]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Thanks, I can repro with that.

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

This bug is an edge case that we should fix but that won't block the 37 release. I have marked 37 as wontfix.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Jeff, do you have plans to work on this during the 38 beta cycle? Thanks

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Not immediate ones. It would be good if we could get a regression window though.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Florin, do you know if anyone can reproduce this? Thanks

Comment 14

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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.

Comment 15

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Thanks Florin, you rock!

David, can you help on this issue? Thanks

Comment 17

[David Parks [:handyman]]

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?

Comment 18

[Steven Michaud [:smichaud] (Retired)]

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?

Comment 19

[Sylvestre Ledru [:Sylvestre]]

Milan, who is the "backup" of Benoit when he is off?

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 21

[Jet Villegas (inactive)]

Attachment: Adds back the visibility check for Mac plugins

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.

Comment 22

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 23

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ff5588b74fa4

Comment 24

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/ff5588b74fa4

Comment 25

[Sylvestre Ledru [:Sylvestre]]

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

Comment 26

[Jet Villegas (inactive)]

[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

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8597547 [details] [diff] [review]
Adds back the visibility check for Mac plugins

Setting the correct flags (see the previous comment)

Comment 28

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8597547 [details] [diff] [review]
Adds back the visibility check for Mac plugins

Too late for 38 but taking it for 39.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8d0f31b22060

Comment 30

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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?

Comment 31

[Andrei Vaida [:avaida]]

(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?

Comment 32

[Jet Villegas (inactive)]

(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

Comment 33

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(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.

Comment 34

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Jet, any thoughts on the results above in comment 33?

Comment 35

[Jet Villegas (inactive)]

(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

Comment 36

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: 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.

Comment 37

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Jet, any success reproducing this?

Comment 38

[Jet Villegas (inactive)]

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.

Comment 39

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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?

Comment 40

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Removing qe-verify+ flag since this was tested and it's importance has diminished.

Comment 41

[Jet Villegas (inactive)]

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!

Comment 42

[Benoit Girard (:BenWa)]

I get 30 FPS on that tab but 0 FPS when it's in the background. Looks good, thank you Jet!