-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spec should clarify value of renderingTimestamp
whenever there is no next rendering opportunity.
#123
Comments
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Dec 21, 2022
EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jan 17, 2023
EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Jan 17, 2023
EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jan 17, 2023
EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jan 17, 2023
EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Jan 20, 2023
…hanged, for Event Timing, a=testonly Automatic update from web-platform-tests Ignore presentation time if visibility changed, for Event Timing EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452} -- wpt-commits: 961cd0162bcebbb0acfe94bbf21a5ece067374d0 wpt-pr: 37039
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Jan 25, 2023
…hanged, for Event Timing, a=testonly Automatic update from web-platform-tests Ignore presentation time if visibility changed, for Event Timing EventTiming registers for presentation feedback times for events which are expected to have a visual update. However, if page visibility changes, that can affect the time it takes to present the next paint update. We were already ignoring the time to next paint portion for UKM reporting of interactions, but now we also ignore this time for Event Timing reporting to Web Performance timeline. Filed a spec issue with EventTiming API to clarify cases where events will not have a next paint: w3c/event-timing#123 Also, we will follow-up to see if it is not desirable to measure all the way until visibility change, as per: w3c/event-timing#129 Bug: 1312568 Change-Id: Iee0b5eee81fb216a96ecbfcc41ca26601ab6ba1b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926369 Commit-Queue: Michal Mocny <[email protected]> Auto-Submit: Michal Mocny <[email protected]> Reviewed-by: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1093452} -- wpt-commits: 961cd0162bcebbb0acfe94bbf21a5ece067374d0 wpt-pr: 37039
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Event Timing Entry values receive a
duration
value via arenderingTimestamp
, which is set via Update the Rendering steps of HTML event loop (currently, alongside "mark paint timing").However, this presumes that there will necessarily be an (immediate) next rendering opportunity. Otherwise, the event loop will skip rendering work.
Some examples of cases where this may happen:
In such cases, the
duration
of the Event should probably be relative to theprocessingEnd
time of the event timing entry. I.e., Events are considered complete at the moment when they are finished processing, if there is no visual update following.Alternatively, perhaps
duration
could be set based on the timing of the step in the event loop processing model that decides if there should not need to be a next rendering opportunity. I.e., Event durations should not end right when processing ends, but some short time later, at the start of the turn of the event loop that decided about rendering. Specifically, if there are multiple event types being dispatched consecutively, it may be valuable to delay deciding if there will (eventually) be a rendering opportunity... and even if there eventually isn't an opportunity, there may still be value in ending all those events at that same time point, rather than each processingEnd point.The text was updated successfully, but these errors were encountered: