Closed Bug 1051134 Opened 10 years ago Closed 10 years ago

Eideticker regression in checkerboarding metric for cnn / imgur between Thurs Aug 7 and Fri Aug 8

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

All
Android
defect
Not set
normal

Tracking

(firefox34+ fixed, firefox35 fixed, fennec34+)

RESOLVED FIXED
Firefox 34
Tracking Status
firefox34 + fixed
firefox35 --- fixed
fennec 34+ ---

People

(Reporter: wlach, Assigned: mattwoodrow)

References

Details

(Whiteboard: [eideticker_regression])

Attachments

(1 file)

So Eideticker is now producing results again regularly for the Galaxy Nexus, and we've already found a regression:

http://eideticker.mozilla.org/#/samsung-gn/mozilla-central/cnn/checkerboard/7
http://eideticker.mozilla.org/#/samsung-gn/mozilla-central/imgur/checkerboard/7

Pushlog of range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=18f408a5984e&tochange=5e74101ce59e

There were some graphics commits by :mattwoodrow and :tn for this range, needinfo'ing them.
Flags: needinfo?(tnikkel)
Flags: needinfo?(matt.woodrow)
Any way we can narrow down the range?

My change only changes the offset of a visible rect (not the size), so I would hope that it didn't have any effect on perf.
Flags: needinfo?(tnikkel)
Yeah I can try to narrow down the regression a bit today.
Used mozregression to isolate things a bit more, isolated it to these commits:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=23ea95cbd92f&tochange=dbd45a6fec49

(which means that :tn is off the hook, Matt could you look into this when you get a chance?)
tracking-fennec: --- → ?
Assignee: nobody → matt.woodrow
tracking-fennec: ? → 34+
What exactly do these tests measure? And how would I go about reproducing the issues locally, without the camera setup?

Scrolling on imgur.com seems entirely dependent on image loading, I can't get it to checkerboard at all.
Flags: needinfo?(matt.woodrow)
Whiteboard: [eideticker_regression]
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> What exactly do these tests measure? And how would I go about reproducing
> the issues locally, without the camera setup?

They measure the amount of time where the display was "purple" (i.e. we are waiting for the viewport to redraw) or as we say on the dashboard: "The measure is the sum of the percentages of frames that are checkerboarded over the entire capture. Lower values are better."

Do you have a galaxy nexus? You can reproduce the test environment by running eideticker in no capture mode (and optionally gather similar checkerboarding information using internal metrics).

https://github.com/wlach/eideticker/blob/master/README.md#console-mode

Would a gecko profile be helpful? I could probably gather those without too much effort (we're actually going to be generating eideticker runs with profiling enabled again soon).

> Scrolling on imgur.com seems entirely dependent on image loading, I can't
> get it to checkerboard at all.

I suspect this is highly device dependent.
Flags: needinfo?(matt.woodrow)
I don't have a galaxy nexus, will it work on other devices?

Profiles would be very helpful!
Flags: needinfo?(matt.woodrow)
Sorry for the late response... 

(In reply to Matt Woodrow (:mattwoodrow) from comment #7)
> I don't have a galaxy nexus, will it work on other devices?

In theory yes, though I'm not sure how reproducible the problem would be. If it would be helpful I can give you access to one of the eideticker machines with a device connected.

> Profiles would be very helpful!

Before (nightly from 2014-08-07):

http://people.mozilla.org/~bgirard/cleopatra/?zippedProfile=http://people.mozilla.org/~wlachance/sps-profile-1409021369.06.zip#

After (nightly from 2014-08-09): 

http://people.mozilla.org/~bgirard/cleopatra/?zippedProfile=http://people.mozilla.org/~wlachance/sps-profile-1409021721.19.zip#

Let me know if you need anything else to help track this down.
Flags: needinfo?(matt.woodrow)
I'm not getting anywhere with reproducing this, so this patch just reverts the original changes for mobile only. The bug it was fixing doesn't happen there anyway (because Jeff fixed it differently) so this should be fine.

Solving this using shaders is still the right long term fix :)
Attachment #8479510 - Flags: review?(bas)
Flags: needinfo?(matt.woodrow)
Attachment #8479510 - Flags: review?(bas) → review+
Depends on: 1073554
Matt, what is the status here? This is tracking 34.
Flags: needinfo?(matt.woodrow)
[Tracking Requested - why for this release]: tracking for fennec 34, but seems to have cross product dependencies
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #12)
> Matt, what is the status here? This is tracking 34.

Matt backed out the changes that caused the problem on Android. You can see things going back to normal around Aug 28:

http://eideticker.mozilla.org/#/android/samsung-gn/mozilla-central/imgur/checkerboard/60
Flags: needinfo?(matt.woodrow)
Confirmed that commits are in Aurora.

Only remaining question is if there was a backout that didn't reference the bug number.
Status: NEW → RESOLVED
Closed: 10 years ago
OS: Linux → Android
Hardware: x86_64 → All
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.