959393 - about:start rendering anomaly while scrolling (aurora only)

Status: VERIFIED FIXED

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

Description

[Jim Mathies [:jimm]]

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.

Comment 1

[Matt Brubeck (:mbrubeck)]

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.

Comment 2

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

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.

Comment 3

[Jim Mathies [:jimm]]

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.

Comment 4

[Jim Mathies [:jimm]]

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.

Comment 5

[Matt Brubeck (:mbrubeck)]

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

Comment 6

[Jim Mathies [:jimm]]

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.

Comment 7

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

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.

Comment 8

[Jim Mathies [:jimm]]

Attachment: video

Comment 9

[Jim Mathies [:jimm]]

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.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking for now since this sounds ugly for users' experience.

Comment 11

[Jim Mathies [:jimm]]

This drawing problem changed in the most recent aurora build from a white rect to to a black rect.

Comment 12

[Jim Mathies [:jimm]]

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.

Comment 13

[Jim Mathies [:jimm]]

FWIW, I think this blocks our release on 28. I can reproduce easily every time I scroll about:start.

Comment 14

[Jim Mathies [:jimm]]

Juan, any chance qa might be able to help us find a regression range on aurora?

Comment 15

[Jim Mathies [:jimm]]

will work this up since I'm stuck waiting on builds for other bugs.

Comment 16

[Jim Mathies [:jimm]]

regression range - 

http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=2c8f8683bd0d&tochange=c5109884ae3a

Likely bug 907179 -  Tune APZC displayport heuristics

Comment 17

[Jim Mathies [:jimm]]

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

Comment 18

[Jim Mathies [:jimm]]

Correction, hat log was for the *x* axis.

Comment 19

[Jim Mathies [:jimm]]

Attachment: update skate prefs

This seems to fix it.

Comment 20

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

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.

Comment 21

[Jim Mathies [:jimm]]

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.

Comment 22

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

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

Comment 23

[Jim Mathies [:jimm]]

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

Comment 24

[Jim Mathies [:jimm]]

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

Comment 25

[Jim Mathies [:jimm]]

Attachment: update skate prefs

Comment 26

[Jim Mathies [:jimm]]

Comment on attachment 8365664 [details] [diff] [review]
update skate prefs

oops, that was my debug patch.

Comment 27

[Jim Mathies [:jimm]]

Attachment: update skate prefs

Comment 28

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

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

Comment 29

[Jim Mathies [:jimm]]

https://hg.mozilla.org/integration/fx-team/rev/158bd11e1157

Comment 30

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/158bd11e1157

Comment 31

[Jim Mathies [:jimm]]

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

Comment 32

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/25a52d9f4a62

Comment 33

[Cornel Ionce [:noni] [Hubs QA]]

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

Comment 34

[u279076]

Verified fixed based on comment 33.