Skip to content
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

Open
mmocny opened this issue Sep 30, 2022 · 0 comments
Assignees

Comments

@mmocny
Copy link
Contributor

mmocny commented Sep 30, 2022

Event Timing Entry values receive a duration value via a renderingTimestamp, 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:

  • An event is handled, but there are no updates to the DOM of visual state of the page in any way. The browser decides that the page does not need to update rendering to reflect changes.
  • An event is handled, and there are visual changes to the page, but rendering is throttled for some other reasons. For example, the page visibility is changed to hidden.

In such cases, the duration of the Event should probably be relative to the processingEnd 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.

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
@mmocny mmocny self-assigned this Feb 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant