1167621 - Dead Trigger 2 Demo becomes laggy when multiple assets (enemies) are on screen

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Todd Brais]

Attachment: fx40_vader_dxdiag.txt

Actual Result:
When the user selects to play the 'Dead Trigger 2' demo with e10s enabled, or disabled' the game will become laggy when multiple assets are on screen at a single time (enemies. 
 This is most noticeable when the user first exits the elevator (escape to the roof demo)

Expected Results:
The 'Dead Trigger 2' demo runs smoothly without any lag while multiple assets are on screen

1. With e10s enabled OR disabled; launch the 'Dead Trigger 2' demo
http://beta.unity3d.com/jonas/DT2/

2. Select the first stage/map (Keep the doctor safe)
3. Once game loads, exit the elevator, and observe that demo begins laggy when multiple enemies are displayed at once

Comment 1

[Todd Brais]

Attachment: fx40_vader_support.txt

Comment 2

[u279076]

Thanks for the report. Can you please test this in the latest Chrome release and compare the performance?

Comment 3

[Todd Brais]

Hi Anthony,
 After checking this on the latest Chrome release; there is a slight lag as well; however it's not as noticeable 
 (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #2)
> Thanks for the report. Can you please test this in the latest Chrome release
> and compare the performance?

Comment 4

[u279076]

Thanks Todd, can you also check if this happens in a previous Firefox version starting with Firefox 38? You can find our releases at ftp://ftp.mozilla.org/pub/firefox/releases/.

Comment 5

[Todd Brais]

This does NOT occur when using Firefox 38 (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #4)
> Thanks Todd, can you also check if this happens in a previous Firefox
> version starting with Firefox 38? You can find our releases at
> ftp://ftp.mozilla.org/pub/firefox/releases/.

Comment 6

[u279076]

Thanks Todd, that means this is a regression somewhere in Firefox 40. Can you please use mozregression to narrow this down?

Comment 7

[ssimon]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #6)
> Thanks Todd, that means this is a regression somewhere in Firefox 40. Can
> you please use mozregression to narrow this down?

So, this was my first time using mozregression, but it seems like Firefox 38 from 5-12-2015 is the last good build.  Here is what mozregression said at the end of the pass:

42:22.37 LOG: MainThread Bisector INFO Narrowed inbound regression window from [
be1ccc5b, 3e46e2f1] (3 revisions) to [be1ccc5b, 98cd3686] (2 revisions) (~1 step
s left)
42:22.37 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
42:22.37 LOG: MainThread Bisector INFO Last good revision: be1ccc5b76a0
42:22.37 LOG: MainThread Bisector INFO First bad revision: 98cd3686996b
42:22.37 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=be1ccc
5b76a0&tochange=98cd3686996b

I hope that helps.  I had trouble seeing the bug at first, but the noticeable things that are affected are the responsiveness of the mouse, the delay between clicking and the gun firing, and the smoothness of the enemy animations.  FF 38 seems to perform better than anything mozregression served up.  Is it possible that there is a difference in performance between using mozregression and having the build installed manually?

Comment 8

[u279076]

(In reply to ssimon from comment #7)
> Is it possible that there is a difference in performance between
> using mozregression and having the build installed manually?

The only difference I can think of is that mozregression always starts from an absolute clean state by creating a new temporary profile before starting Firefox and destroying that profile when it quits.

Looking at the range you provided I'm not 100% sure which patch caused this. 

:hiro, bug 1158731 shows up in this range. Do you think something about your patch could cause this?
:stevensn, bug 1162350 shows up in this range. Do you think something about your patch could cause this?

Thanks

Comment 9

[Hiroyuki Ikezoe (:hiro)]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #8)
> Looking at the range you provided I'm not 100% sure which patch caused this. 
> 
> :hiro, bug 1158731 shows up in this range. Do you think something about your
> patch could cause this?

I do not think so. As far as I can confirm the game does not invoke any Performance APIs, so the patch affects nothing against the game.

Comment 10

[Steve Singer (:stevensn)]

I don't think bug 1162350 would cause this, The code change in the #else doesn't get compiled on normal builds.

Comment 11

[u279076]

Hmm, okay. I don't see anything else in the range that could cause this but maybe the range isn't 100% accurate. Todd or ssimon, could one of you try to manually regress this using the builds from our FTP server? I can walk you through the process if/when you're available to help.

Comment 12

[ssimon]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #11)
> Hmm, okay. I don't see anything else in the range that could cause this but
> maybe the range isn't 100% accurate. Todd or ssimon, could one of you try to
> manually regress this using the builds from our FTP server? I can walk you
> through the process if/when you're available to help.

Sure I can do that.  I'm looking at ftp://ftp.mozilla.org/pub/firefox/releases/

We already confirmed that the 38.0 build from 5/12/2015 is good.  Should I just start stepping forward down the list and see where it fails?

Comment 13

[u279076]

(In reply to ssimon from comment #12)
> Sure I can do that.  I'm looking at
> ftp://ftp.mozilla.org/pub/firefox/releases/
> 
> We already confirmed that the 38.0 build from 5/12/2015 is good.  Should I
> just start stepping forward down the list and see where it fails?

Yes please.

Comment 14

[ssimon]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #13)
> (In reply to ssimon from comment #12)
> > Sure I can do that.  I'm looking at
> > ftp://ftp.mozilla.org/pub/firefox/releases/
> > 
> > We already confirmed that the 38.0 build from 5/12/2015 is good.  Should I
> > just start stepping forward down the list and see where it fails?
> 
> Yes please.

Alright, so I've tested 5 builds between 38.0 and 39.0b1 (the latest on the ftp site).  I'm not seeing the issue occur with any of these builds.  39.0b1 performs similarly to 38.0.  40.0a2 still exhibits some slowdown at the beginning of the level when there are a lot of enemies on screen.

Comment 15

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

Anthony, were you suggesting Simon does mozregression?

Comment 16

[u279076]

(In reply to Milan Sreckovic [:milan] from comment #15)
> Anthony, were you suggesting Simon does mozregression?

No, we already tried Mozregression and the range we got does not point to relevant bugs. 

(In reply to ssimon from comment #14)
> 40.0a2 still exhibits some slowdown at the
> beginning of the level when there are a lot of enemies on screen.

This at least confirms the bug is somewhere in Firefox 40. Please test the following builds and let me know which builds reproduce the bug:
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/03/2015-03-31-03-02-04-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-07-03-02-07-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-14-03-02-05-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-21-09-29-28-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-28-03-02-09-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/05/2015-05-05-03-02-06-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe

Comment 17

[ssimon]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #16)
> (In reply to Milan Sreckovic [:milan] from comment #15)
> > Anthony, were you suggesting Simon does mozregression?
> 
> No, we already tried Mozregression and the range we got does not point to
> relevant bugs. 
> 
> (In reply to ssimon from comment #14)
> > 40.0a2 still exhibits some slowdown at the
> > beginning of the level when there are a lot of enemies on screen.
> 
> This at least confirms the bug is somewhere in Firefox 40. Please test the
> following builds and let me know which builds reproduce the bug:
> *
> ftp://ftp.mozilla.org/pub/firefox/nightly/2015/03/2015-03-31-03-02-04-
> mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
> *
> ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-07-03-02-07-
> mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
> *
> ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-14-03-02-05-
> mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
> *
> ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-21-09-29-28-
> mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
> *
> ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-28-03-02-09-
> mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
> *
> ftp://ftp.mozilla.org/pub/firefox/nightly/2015/05/2015-05-05-03-02-06-
> mozilla-central/firefox-40.0a1.en-US.win32.installer.exe

I've finished testing all 6 of the above builds.

The first two builds (2015-03-31 and 2015-04-07) both have a separate issue where the mouse sensitivity/mouse acceleration is way too high and makes the game unplayable.  Since part of the bug we are trying to test deals with mouse responsiveness, these two builds are not very helpful due to the presence of this separate issue.

The next 4 builds (2015-04-14, 2015-04-21, 2015-04-28, and 2015-05-05) all exhibit the bug we are looking for.  Since it seems whatever issue was present in the first two builds is not present in any of these, I'm inclined to wonder if the fix that was implemented to remedy the high mouse sensitivity / acceleration is responsible for the feeling of lag described in the current bug (1167621).  Mouse responsiveness is certainly one of the differences that is apparent when looking at ff 38.0 vs ff 40.

Comment 18

[u279076]

Thanks for the testing. Can you please check the following builds?

* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-08-03-02-05-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-09-03-02-06-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-10-03-02-04-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-11-03-02-07-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-12-03-02-33-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe
* ftp://ftp.mozilla.org/pub/firefox/nightly/2015/04/2015-04-13-03-02-03-mozilla-central/firefox-40.0a1.en-US.win32.installer.exe

Comment 19

[ssimon]

It looks like the build from 2015-04-08 has the mouse sensitivity issue.

Build 2015-04-09 and every one after it has the bug present.

Hope this helps to narrow it down.

Comment 20

[u279076]

Thanks Simon, this is the new regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=078128c2600a&tochange=8f57f60ee58a

Milan, I know there's a lot of change in that log but does anything jump out at you?

Comment 21

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

Nothing really, not clear it is actually graphics related.  Same problem on non-e10s?

Comment 22

[u279076]

(In reply to Milan Sreckovic [:milan] from comment #21)
> Nothing really, not clear it is actually graphics related.  Same problem on
> non-e10s?

Yes, e10s on or off does not impact the reproducibility of this bug.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

There's a bunch of WebGL-related changes in the pushlog in comment 20:
a7dbe1bc7878	Jeff Gilbert — Bug 1009734 - Wait until draw to warn about texture completeness. - r=kamidphish
decbad9a43db	Jeff Gilbert — Bug 1150767 - Add pref for requiring hardware-backed GL. - r=jrmuizel
4fe77ea803ee	Jeff Gilbert — Bug 1150762 - Add pref for activating all ANGLE options. - r=kamidphish
5d2557bbf777	Jeff Gilbert — Bug 1150760 - Don't call workaround unless necessary. - r=kamidphish

Though from the *ahem* research *ahem* I did, the demo played pretty smoothly on a current trunk build on Win10. Is this still reproducible for others?

Comment 24

[u279076]

We'd need someone from Betabreakers to retest this. I can add this to the to-do list for the next testrun we schedule

Comment 25

[Trammel May]

Cannot replicate bug. No lag, really smooth. Tested on Firefox Dev 43