|
|
DescriptionSkTime updates
1) Use steady_clock instead of high_resolution_clock. If we don't have a
guarantee of monotonicity, it's pretty much useless for timing things.
2) Implement Mac/iOS with <chrono> too. This was waiting on C++11 library support.
Both high_resolution_clock and steady_clock are (still) busted on MSVC 2013,
so no change there.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/6a20871e5aeaa7e61f3348694bf436af16f824b9
Patch Set 1 #Patch Set 2 : No MSVC. #Messages
Total messages: 18 (9 generated)
Description was changed from ========== SkTime updates 1) Use steady_clock instead of high_resolution_clock. If we don't have a guarantee of monotonicity, it's pretty much useless for timing things. 2) Implement all platforms with <chrono>. This was waiting on C++11 library support and high_resolution_clock -> steady_clock on Windows. BUG=skia: ========== to ========== SkTime updates 1) Use steady_clock instead of high_resolution_clock. If we don't have a guarantee of monotonicity, it's pretty much useless for timing things. 2) Implement all platforms with <chrono>. This was waiting on C++11 library support on Mac and high_resolution_clock -> steady_clock on Windows. BUG=skia: ==========
Description was changed from ========== SkTime updates 1) Use steady_clock instead of high_resolution_clock. If we don't have a guarantee of monotonicity, it's pretty much useless for timing things. 2) Implement all platforms with <chrono>. This was waiting on C++11 library support on Mac and high_resolution_clock -> steady_clock on Windows. BUG=skia: ========== to ========== SkTime updates 1) Use steady_clock instead of high_resolution_clock. If we don't have a guarantee of monotonicity, it's pretty much useless for timing things. 2) Implement Mac/iOS with <chrono> too. This was waiting on C++11 library support. Both high_resolution_clock and steady_clock are (still) busted on MSVC 2013, so no change there. BUG=skia: ==========
The CQ bit was checked by mtklein@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1521293002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1521293002/20001
The CQ bit was unchecked by mtklein@google.com
mtklein@chromium.org changed reviewers: + herb@google.com - mtklein@google.com
I wrote this thinking that it'd fix some of those negative time problems you were seeing on the Nexus 9 a couple weeks ago. But now I can't see them. Where were they?
They were on Denver in Release only. Some of the individual DM times were negative.
lgtm
The CQ bit was checked by mtklein@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1521293002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1521293002/20001
The CQ bit was unchecked by commit-bot@chromium.org
Exceeded global retry quota
The CQ bit was checked by mtklein@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1521293002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1521293002/20001
Message was sent while issue was closed.
Description was changed from ========== SkTime updates 1) Use steady_clock instead of high_resolution_clock. If we don't have a guarantee of monotonicity, it's pretty much useless for timing things. 2) Implement Mac/iOS with <chrono> too. This was waiting on C++11 library support. Both high_resolution_clock and steady_clock are (still) busted on MSVC 2013, so no change there. BUG=skia: ========== to ========== SkTime updates 1) Use steady_clock instead of high_resolution_clock. If we don't have a guarantee of monotonicity, it's pretty much useless for timing things. 2) Implement Mac/iOS with <chrono> too. This was waiting on C++11 library support. Both high_resolution_clock and steady_clock are (still) busted on MSVC 2013, so no change there. BUG=skia: Committed: https://skia.googlesource.com/skia/+/6a20871e5aeaa7e61f3348694bf436af16f824b9 ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001) as https://skia.googlesource.com/skia/+/6a20871e5aeaa7e61f3348694bf436af16f824b9
Message was sent while issue was closed.
A revert of this CL (patchset #2 id:20001) has been created in https://codereview.chromium.org/1529603002/ by mtklein@google.com. The reason for reverting is: linux Canary builder has no std::steady_clock. Weird.... |