Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2289173003:
Make event timestamp consistent in renderer even if TimeTicks isn't consistent x-process. (Closed)
|
Created:
4 years, 3 months ago by majidvp Modified:
4 years, 3 months ago Reviewers:
dtapuska CC:
chromium-reviews, mlamouri+watch-content_chromium.org, jam, darin-cc_chromium.org, dtapuska+chromiumwatch_chromium.org, tdresser Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionUse IO thread time for event timestamp if TimeTicks isn't consistent x-process.
On some platforms (a subset of Windows) we don't have a monotonic clock that
is consistent across processes. On such platforms we cannot reliably compare
timeticks that are from different processes.
This is particularly problematic for WebInputEvent whose timestamp comes
from UI process but is consumed by the renderer process and eventually exposed
to the web as high-resolution timestamp.
This patch introduces a fallback where we use the message received time on the
renderer IO thread (i.e., the earliest time we get the message on the renderer)
as the event timestamp and sidestep the inconsistency.
BUG=642714
Committed: https://crrev.com/5802f789601b88d99f72d8ed081651df4b3fdf4b
Cr-Commit-Position: refs/heads/master@{#416737}
Patch Set 1 #Patch Set 2 : rebae #
Messages
Total messages: 20 (14 generated)
The CQ bit was checked by majidvp@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...) android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...) android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...) cast_shell_android on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...) linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...) cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...) chromeos_amd64-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...) chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...) chromeos_x86-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...) chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...) linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by majidvp@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Make event timestamp consistent in renderer even if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=616787 ========== to ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=616787 ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
majidvp@chromium.org changed reviewers: + dtapuska@chromium.org
Description was changed from ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=616787 ========== to ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=642714 ==========
On 2016/08/31 12:23:39, majidvp wrote: dtapuska@: friendly ping!
On 2016/09/06 20:10:34, majidvp wrote: > On 2016/08/31 12:23:39, majidvp wrote: > > dtapuska@: friendly ping! lgtm!
The CQ bit was checked by majidvp@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=642714 ========== to ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=642714 ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Description was changed from ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=642714 ========== to ========== Use IO thread time for event timestamp if TimeTicks isn't consistent x-process. On some platforms (a subset of Windows) we don't have a monotonic clock that is consistent across processes. On such platforms we cannot reliably compare timeticks that are from different processes. This is particularly problematic for WebInputEvent whose timestamp comes from UI process but is consumed by the renderer process and eventually exposed to the web as high-resolution timestamp. This patch introduces a fallback where we use the message received time on the renderer IO thread (i.e., the earliest time we get the message on the renderer) as the event timestamp and sidestep the inconsistency. BUG=642714 Committed: https://crrev.com/5802f789601b88d99f72d8ed081651df4b3fdf4b Cr-Commit-Position: refs/heads/master@{#416737} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/5802f789601b88d99f72d8ed081651df4b3fdf4b Cr-Commit-Position: refs/heads/master@{#416737} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
