Open Bug 791744 Opened 13 years ago Updated 1 year ago

Imgur reflow time is highly variable

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
macOS
Type:
defect

Tracking

()

People

(Reporter: BenWa, Unassigned)

Details

How are you measuring this time?
The scores are measured using checkerboarding (pink in the videos). The 'variable time' is measured by the difference in numbers of samples being spent in reflow. The difference in over 10 times which is very significant. The trend continued again today.
No, I meant when do you start and stop measuring?
I'm looking at the test run as a whole. The test runs by executing a set of touch events and sleeps and dumps the profile.
OK. So the usual reasons reflow times might be variable, basically are: 1) Start and stop times for the profiling/measuring not being correlated with when reflows might actually happen (e.g. starting profiling partway through a page load). 2) Different network behavior actually leading to content coming in with different timing, such that an extra incremental reflow has to happen in some cases but not others.
Will my patch in bug 792302 help by printing a reflow reason?
We can rule out 1) since we record from startup to after navigating away from imgur. The expensive reflow seems to be happening during panning instead of page load but I can't tell for sure. Frame sync profile and bug 792302 should tell us for sure.
(In reply to comment #7) > We can rule out 1) since we record from startup to after navigating away from > imgur. The expensive reflow seems to be happening during panning instead of > page load but I can't tell for sure. Frame sync profile and bug 792302 should > tell us for sure. Do you know what this page does which causes it to reflow during panning?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.