Repository navigation
fix(timestamp): eliminate f64 timebase drift and mantissa truncation in long recordings (#2144) - #3936
fix(timestamp): eliminate f64 timebase drift and mantissa truncation in long recordings (#2144)#3936frds3445 wants to merge 3 commits into
Conversation
…dings Replace f64 timebase division and u64-to-f64 epoch casts in MachAbsoluteTimestamp and PerformanceCounterTimestamp with 128-bit integer rational arithmetic so cursor and video timelines remain synchronized across multi-hour recordings. Fixes CapSoftware#2144 Signed-off-by: Lucas Oliveira <kalopsia3445@gmail.com>
|
@frds3445 is attempting to deploy a commit to the Cap Software Inc Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| let high_uptime_ticks: u64 = 1u64 << 52; | ||
| let step_ticks = nanos_to_ticks_with_ratio(3_600_000_000_000, numer, denom); | ||
| let later_ticks = high_uptime_ticks.saturating_add(step_ticks); | ||
| let elapsed_ns = ticks_to_nanos_with_ratio(later_ticks - high_uptime_ticks, numer, denom); | ||
| assert_eq!(elapsed_ns, 3_600_000_000_000); |
There was a problem hiding this comment.
Both new tests use a whole-hour value that the old floating-point math also represents exactly. This macOS test also adds the large base directly with integer arithmetic, bypassing the MachAbsoluteTimestamp operators where precision was lost. The old math could return without these tests failing.
Add a case that exercises the timestamp operators with a base above 2^53 whose low bit is set. Adding Duration::ZERO, for example, must preserve that base exactly. Include fractional durations in the Windows test too.
Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/timestamp/src/macos.rs
Line: 145-149
Comment:
**Tests miss the precision loss**
Both new tests use a whole-hour value that the old floating-point math also represents exactly. This macOS test also adds the large base directly with integer arithmetic, bypassing the `MachAbsoluteTimestamp` operators where precision was lost. The old math could return without these tests failing.
Add a case that exercises the timestamp operators with a base above `2^53` whose low bit is set. Adding `Duration::ZERO`, for example, must preserve that base exactly. Include fractional durations in the Windows test too.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
…ross high uptimes
…d Windows Use a base timestamp above 2^53 with the low bit set in macos.rs and win.rs tests and cover Add/Sub/AddAssign/SubAssign operator roundtrips.
Summary
Eliminates cumulative
f64timebase drift between cursor telemetry and video frames during long recordings (#2144):u128/i128) arithmetic anchored to a shared monotonic recording epoch before converting to rational media timestamps, preventing floating-point mantissa truncation over multi-hour sessions.Fixes #2144
/claim #2144
The PR appears safe to merge, with a non-blocking gap in its precision tests.
Findings
Fix with agent prompt
Summary
Replaces floating-point timestamp arithmetic with integer conversions on macOS and Windows.
Reviews (1) · Last reviewed commit: "fix(timestamp): eliminate float precisio..." · Reviewed by Greptile