Closed Bug 1386968 Opened 3 years ago Closed 3 years ago

Collect telemetry on the value of triple or n-buffering

Categories

(Core :: Graphics: Layers, enhancement, P3)

40 Branch
enhancement

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox-esr52 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- fix-optional
firefox58 --- fixed

People

(Reporter: dvander, Assigned: dvander)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

Mason brought this up today, I'm filing now to get it on record. Currently OMTP is limited to buying us an extra 16ms of rasterization time. That is, if everything else in a frame takes 10ms, with synchronous painting we have 6ms left over to spend. OMTP bumps that to 22ms. We can't let content get further ahead than that since content and canvas are double buffered - we wouldn't be able to flip buffers.

We should get Telemetry on whether it's worth improving on this - maybe timing how long we spend flushing paints would do it?
Assignee: nobody → mchang
Priority: -- → P3
Whiteboard: [gfx-noted]
Assignee: mchang → rhunt
Stealing by accident, I didn't see this was assigned before I started...

There's two new probes here. One is a histogram that shows us the time spent blocking waiting for the paint thread. Here we're mainly looking for outliers, which helps see how bad we're blocking the main thread and whether n-buffering would help. We only record this probe if we wait for more than 200us.

The second probe is a scalar that tells us how often we block for more than 200us. Without this we don't have context for the histogram and its first bucket is difficult to analyze.
Assignee: rhunt → dvander
Status: NEW → ASSIGNED
Attachment #8915462 - Flags: review?(milan)
Comment on attachment 8915462 [details] [diff] [review]
bug1386968-part1.patch

data review
Attachment #8915462 - Flags: review?(francois)
(In reply to David Anderson [:dvander] from comment #1)
> Created attachment 8915462 [details] [diff] [review]
> bug1386968-part1.patch
> 
> Stealing by accident, I didn't see this was assigned before I started...
> 
> There's two new probes here. One is a histogram that shows us the time spent
> blocking waiting for the paint thread. Here we're mainly looking for
> outliers, which helps see how bad we're blocking the main thread and whether
> n-buffering would help. We only record this probe if we wait for more than
> 200us.
> 
> The second probe is a scalar that tells us how often we block for more than
> 200us. Without this we don't have context for the histogram and its first
> bucket is difficult to analyze.

I wasn't actively doing this so there's no problem.

One thing I think remember seeing when investigating other OMTP stuff is that FlushAsyncPaints can block not only for when one window is trying to paint another frame ahead, but also in some cases where there are two windows in one content process and the second one wishes to paint while the other one is finishing an async paint.

I don't know how common this is, I had to go out of my way to reproduce it.
Attachment #8915462 - Flags: review?(milan) → review+
Comment on attachment 8915462 [details] [diff] [review]
bug1386968-part1.patch

Review of attachment 8915462 [details] [diff] [review]:
-----------------------------------------------------------------

datareview+

::: toolkit/components/telemetry/Histograms.json
@@ +13720,5 @@
>      "description": "Milliseconds between starting to fill an autofill-eligible form field and submitting the form, keyed by the combination of form type and filling type."
> +  },
> +  "GFX_OMTP_PAINT_WAIT_TIME": {
> +    "record_in_processes": ["content"],
> +    "alert_emails": ["gfx-telemetry-alerts@mozilla.com"],

ditto: add your email

@@ +13725,5 @@
> +    "expires_in_version": "61",
> +    "kind": "exponential",
> +    "high": 200,
> +    "n_buckets": 50,
> +    "description": "Amount of time in milliseconds the main thread spends waiting for the paint thread to complete, if the time was greater than 200us.",

Just to confirm that this is not a typo: the unit of the measurement is milliseconds, but the threshold is in microseconds?

::: toolkit/components/telemetry/Scalars.yaml
@@ +943,5 @@
> +    keyed: false
> +    kind: uint
> +    expires: "61"
> +    notification_emails:
> +      - gfx-telemetry-alerts@mozilla.com

Please add your email address here (or someone else's if you prefer). Including a team email is fine, but we now require that all probes also include the email of a person.
Attachment #8915462 - Flags: review?(francois) → review+
(In reply to François Marier [:francois] from comment #4)
>
> Just to confirm that this is not a typo: the unit of the measurement is
> milliseconds, but the threshold is in microseconds?

Yup, that's right.
Pushed by danderson@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/18cc24d492a0
Collect data on how long the main thread blocks on the paint thread. (bug 1386968, r=milan, data_r=francois)
https://hg.mozilla.org/mozilla-central/rev/18cc24d492a0
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Blocks: 1518669
You need to log in before you can comment on or make changes to this bug.