Closed Bug 959393 Opened 6 years ago Closed 6 years ago

about:start rendering anomaly while scrolling (aurora only)

Categories

(Firefox for Metro Graveyard :: Firefox Start, defect, P2)

28 Branch
x86_64
Windows 8.1
defect

Tracking

(firefox28+ verified, firefox29 verified)

VERIFIED FIXED
Firefox 29
Tracking Status
firefox28 + verified
firefox29 --- verified

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Keywords: regression, Whiteboard: [release28] [defect] p=3)

Attachments

(2 files, 2 obsolete files)

str:

1) load up aurora and scroll about:start to the right

result: a white band flashes into view on the left side of the screen when scrolling starts. Testing on a surface pro.

I cant reproduce this on mozilla-central.
Whiteboard: [triage] [defect] p=0
This sounds like maybe the displayport is set to the screen size (instead of slightly larger than the screen).  Are there any displayport-related patches that are not on Aurora yet?  We could also use some remote debugging to peek at the code that sets the displayport.
As far as I know all the displayport calculation changes should have been uplifted. (The latest was bug 907179). It's possible I missed something though.
The drawing issues isn't just at the start of the scroll, you can reproduce as you scroll farther in. You have to scroll pretty fast to trigger. Scrolling back and forth off the left side of the page repeatedly will reproduce eventually.
Also, the white strip doesn't seem to impact tiles, just background, so maybe this is a gfx regression? I think a regression range is a good place to start.
I'm not seeing this in an Aurora build on my Surface Pro 2.  When scrolling as fast as I can, I get a little bit of black "checkerboard", but that affects both background and foreground.

Since this is background-only, maybe related to bug 946502?  Do you still see it if you remove the background-attachment style on the start page?  (You can do this using the remote devtools Inspector.)
you don't have to scroll fast, just back and forth off the left edge. Also i noticed tonight that this impacts tiles as well so its not background specific.
Can you set apz.x_skate_size_multiplier and apz.x_stationary_size_multiplier both to "5.0" and see if that fixes the problem? If it does then it's just the displayport not being wide enough. The displayport size is optimized for vertically scrolling things rather than horizontally scrolling things.
Attached video video
https://skydrive.live.com/?cid=04DFF3F04A5AB6D0&id=4DFF3F04A5AB6D0!3737&v=3

Here's the inline skydrive movie if you can't get that to play.
Whiteboard: [triage] [defect] p=0 → [release28] [defect] p=0
Tracking for now since this sounds ugly for users' experience.
Whiteboard: [release28] [defect] p=0 → [release28] [defect] p=8
This drawing problem changed in the most recent aurora build from a white rect to to a black rect.
I did a local build of aurora on a surface pro 2 and was able to reproduce. Haven't had a chance to debug deeply though. Unfortunately the apz code has diverged quite a bit from mc due to pointer events, making it hard to track down individual differences that might cause this.
FWIW, I think this blocks our release on 28. I can reproduce easily every time I scroll about:start.
Juan, any chance qa might be able to help us find a regression range on aurora?
Flags: needinfo?(jbecerra)
will work this up since I'm stuck waiting on builds for other bugs.
Flags: needinfo?(jbecerra)
Assignee: nobody → jmathies
Whiteboard: [release28] [defect] p=8 → [release28] [defect] p=3
Looks like the logic in EnlargeDisplayPortAlongAxis isn't working very well. This is the output for the y axis when dragging the start page off the left bounds. Note the x origin moves all the way out to 233.516663 before falling back. The total distance of the drag was only about ~150 pixels. The faster you 'jerk' the the page over, the worse this offset becomes. (velOffset is the value for aVelocity * aEstimatedPaintDurationMillis).

MetroWidget::ApzContentIgnoringTouch
APZC: 0F880B28 got a touch-move in state 2
APZC: 0F880B28 got a touch-move in state 2
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=stati aEstimatedPaintDurationMillis=65.157561 velocity=0.430000 velOffset=28.017754 multiplier=3.000000
Calculated displayport as (-6.450000 0.000000 2486.000000 705.000000) from velocity (0.600000 0.000000) acceleration (1.000000 1.000000) paint time 65.157562 metrics
0F880B28 requesting content repaint
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=skate aEstimatedPaintDurationMillis=81.920924 velocity=9.227083 velOffset=755.891174 multiplier=1.500000
Calculated displayport as (233.516663 0.000000 2064.000000 705.000000) from velocity (12.875000 0.000000) acceleration (1.000000 1.000000) paint time 81.920921 metrics
0F880B28 requesting content repaint
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=skate aEstimatedPaintDurationMillis=85.700630 velocity=7.692223 velOffset=659.228333 multiplier=1.500000
Calculated displayport as (84.449982 0.000000 2064.000000 705.000000) from velocity (10.733334 0.000000) acceleration (1.000000 1.000000) paint time 85.700630 metrics
0F880B28 requesting content repaint
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=skate aEstimatedPaintDurationMillis=83.340880 velocity=2.418750 velOffset=201.580765 multiplier=1.500000
Calculated displayport as (-142.419312 0.000000 2064.000000 705.000000) from velocity (3.375000 0.000000) acceleration (1.000000 1.000000) paint time 83.340881 metrics
0F880B28 requesting content repaint
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=stati aEstimatedPaintDurationMillis=65.973593 velocity=0.179167 velOffset=11.820270 multiplier=3.000000
Calculated displayport as (-417.816681 0.000000 2486.000000 705.000000) from velocity (0.250000 0.000000) acceleration (1.000000 1.000000) paint time 65.973595 metrics
0F880B28 requesting content repaint
APZC: 0F880B28 got a touch-move in state 4
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=stati aEstimatedPaintDurationMillis=67.458549 velocity=0.047778 velOffset=3.223020 multiplier=3.000000
Calculated displayport as (-419.250031 0.000000 2486.000000 705.000000) from velocity (0.066667 0.000000) acceleration (1.000000 1.000000) paint time 67.458549 metrics
0F880B28 requesting content repaint
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-move in state 4
APZC: mode=stati aEstimatedPaintDurationMillis=65.520198 velocity=-0.017200 velOffset=-1.126947 multiplier=3.000000
Calculated displayport as (-417.100037 0.000000 2486.000000 705.000000) from velocity (-0.024000 0.000000) acceleration (1.000000 1.000000) paint time 65.520195 metrics
0F880B28 requesting content repaint
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
APZC: 0F880B28 got a touch-move in state 4
0F880B28 got a NotifyLayersUpdated with aIsFirstPaint=0
APZC: 0F880B28 got a touch-end in state 4
APZC: mode=stati aEstimatedPaintDurationMillis=80.453677 velocity=-0.095556 velOffset=-7.687797 multiplier=3.000000
Calculated displayport as (-414.950043 0.000000 2486.000000 705.000000) from velocity (-0.133333 0.000000) acceleration (1.000000 1.000000) paint time 80.453674 metrics
0F880B28 requesting content repaint
APZC: mode=stati aEstimatedPaintDurationMillis=80.453677 velocity=0.000000 velOffset=0.000000 multiplier=3.000000
Calculated displayport as (-414.950043 0.000000 2486.000000 705.000000) from velocity (0.000000 0.000000) acceleration (1.000000 1.000000) paint time 80.453674 metrics
Correction, hat log was for the *x* axis.
Attached patch update skate prefs (obsolete) — Splinter Review
This seems to fix it.
Thanks for digging into this! Those pref changes will help for sure. Something else we could look into is storing a few consecutive velocity values and averaging, rather than using the instantaneous velocity. That will reduce the effect of the 'jerk' when you first start panning.
I can try that. Also I think that the average paint times coming from the paint throttler might be some what unreliable during early in startup. I wonder if we should clamp that value to 50msec or so prior to the first 10-20 paints.

Note, all of my testing was in a clone of aurora prior to bug 931028 uplift. Will update and retest today with that.
(In reply to Jim Mathies [:jimm] from comment #21)
> I can try that. Also I think that the average paint times coming from the
> paint throttler might be some what unreliable during early in startup. I
> wonder if we should clamp that value to 50msec or so prior to the first
> 10-20 paints.

If we do clamp it, we should make that value preffable. On B2G devices which are pretty slow painting can definitely take >50ms.
Hey kats, shouldn't aOutLength get widened by this value as well?

*aOutOffset += (aVelocity * aEstimatedPaintDurationMillis);

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#1280
Actually, with tweaked prefs and that patch, things look pretty tame. This is from a quick drag right and then back left to the stop on about start:

Calculated displayport as (-37.266666 0.000000 2486.000000 705.000000) from velocity (3.250000 0.000000) acceleration (1.000000 1.000000) paint time 0.000000 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-222.166687 0.000000 2486.000000 705.000000) from velocity (13.437500 0.000000) acceleration (1.000000 1.000000) paint time 82.535515 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-446.483368 0.000000 2486.000000 705.000000) from velocity (4.750000 0.000000) acceleration (1.000000 1.000000) paint time 63.512821 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-589.816711 0.000000 2486.000000 705.000000) from velocity (9.533334 0.000000) acceleration (1.000000 1.000000) paint time 66.276863 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-637.116699 0.000000 2486.000000 705.000000) from velocity (0.437500 0.000000) acceleration (1.000000 1.000000) paint time 50.551701 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-611.316711 0.000000 2486.000000 705.000000) from velocity (-1.500000 0.000000) acceleration (1.000000 1.000000) paint time 50.063892 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-477.300018 0.000000 2486.000000 705.000000) from velocity (-4.562500 0.000000) acceleration (1.000000 1.000000) paint time 38.135342 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-293.833344 0.000000 2486.000000 705.000000) from velocity (-3.250000 0.000000) acceleration (1.000000 1.000000) paint time 39.753117 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (-22.933334 0.000000 2486.000000 705.000000) from velocity (-19.312500 0.000000) acceleration (1.000000 1.000000) paint time 54.143246 metrics
0A021268 requesting content repaint
0A021268 got a NotifyLayersUpdated with aIsFirstPaint=0
Calculated displayport as (0.000000 0.000000 2486.000000 705.000000) from velocity (0.000000 0.000000) acceleration (1.000000 1.000000) paint time 58.699341 metrics
0A021268 requesting content repaint
Calculated displayport as (0.000000 0.000000 2486.000000 705.000000) from velocity (0.000000 0.000000) acceleration (1.000000 1.000000) paint time 58.699341 metrics
Attached patch update skate prefs (obsolete) — Splinter Review
Attachment #8365597 - Attachment is obsolete: true
Attachment #8365664 - Flags: review?(bugmail.mozilla)
Comment on attachment 8365664 [details] [diff] [review]
update skate prefs

oops, that was my debug patch.
Attachment #8365664 - Flags: review?(bugmail.mozilla)
Attachment #8365664 - Attachment is obsolete: true
Attachment #8365665 - Flags: review?(bugmail.mozilla)
Attachment #8365665 - Flags: review?(bugmail.mozilla) → review+
(In reply to Jim Mathies [:jimm] from comment #23)
> Hey kats, shouldn't aOutLength get widened by this value as well?
> 
> *aOutOffset += (aVelocity * aEstimatedPaintDurationMillis);
> 
> http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/
> AsyncPanZoomController.cpp#1280

No, the intention of that line is to bias the painting in the direction of the panning. Without that line we'll always paint the same amount on all sides of the currently visible area, but with that line we'll shift that request towards the content we're moving towards.

If we increase aOutLength by that amount we're going to be painting entire "track" from where we are now to where we're going to be in the future. While this sounds nice in theory it means a lot more painting, which means it'll take a lot more time. In practice we've found that the extra paint time makes it not worthwhile - by the time the paint is done we're already outside that area.
Blocks: metrov1it23
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
https://hg.mozilla.org/mozilla-central/rev/158bd11e1157
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8365665 [details] [diff] [review]
update skate prefs

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 907179
User impact if declined: odd drawing behavior
Testing completed (on m-c, etc.): yes
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none
Attachment #8365665 - Flags: approval-mozilla-aurora?
Attachment #8365665 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0

Verified as fixed using the STR from the description with a Surface Pro 2 device on: 
- latest Nightly (build ID: 20140206030201)
- latest Aurora (build ID: 20140206004003)
- Firefox 28 beta 1 (build ID: 20140205162153).
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.