Skip to content

test(motion): a retarget behind a block fails by name when starved #10784

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.

Sign up for GitHub

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

Merged
cixzhang merged 1 commit into from
Nov 9, 2026
Merged

test(motion): a retarget behind a block fails by name when starved #10784

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 29 additions & 9 deletions packages/core/src/motion/__tests__/animator.interaction.browser.spec.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@ import {
countBetween,
markElement,
pageTimesOnControls,
requireFrames,
startBusyControl,
startScreencast,
traceRendering,
Expand Down Expand Up @@ -907,15 +908,16 @@ for (const how of ['in a task', 'in a frame callback of the page'] as const) {
ahead: second,
controlStarts: [controlStart, secondStart],
});
const timed = tracked.flatMap(f => {
const dated = tracked.flatMap(f => {
const at = pageTime.get(f.t);
if (f.box == null || at == null) {
return [];
}
return at >= run.call - 50 && at <= run.end + 150
? [{x: f.box.x - MARKER_INSET, at}]
: [];
return [{x: f.box.x - MARKER_INSET, at}];
});
const timed = dated.filter(
({at}) => at >= run.call - 50 && at <= run.end + 150,
);
// The frames fit the first curve up to a start at or after the block's
// end. After that start, they fit a spring from the value and the velocity
// on screen there. `skip` fits the same frames to the call's own clock
Expand Down Expand Up @@ -981,15 +983,33 @@ for (const how of ['in a task', 'in a frame callback of the page'] as const) {
description: JSON.stringify({read, timed}),
});
// The compositor showed the first curve through the block, and the frames
// after it show the call.
expect(read.inBlock, JSON.stringify(read)).toBeGreaterThanOrEqual(3);
expect(read.after, JSON.stringify(read)).toBeGreaterThanOrEqual(3);
// after it show the call. A loaded runner can present no frame for over
// 100 ms after the block. Too few frames there cannot tell the call's
// clock from the screen's, so such a run fails by name, with its gaps.
// The gaps are read on the controls' clock, past the window's edges too.
const onClock = dated.map(({x, at}) => ({t: at, x}));

@astracat-bot astracat-bot Bot Nov 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking: onClock keeps the cast's stamp order, but its t is the controls' clock. Under load, a frame stamped late sits after frames it came before, and requireFrames reads gaps between array neighbours, so the reported longest gap can grow: frames at 5, 30, 47 and 160 ms after the block report 113 ms in time order and 130 ms when the frame at 30 is stamped late. The frame count and the pass or fail do not change.

const onClock = inPresentationOrder(dated.map(({x, at}) => ({t: at, x})));

inPresentationOrder is already exported by the harness.

requireFrames(onClock, {
min: 3,
during: 'the first curve played through the block',
where: frame => frame.t > run.call && frame.t < run.end,
});
requireFrames(onClock, {
min: 3,
during: 'the call played in the 130 ms after the block',
where: frame => frame.t > run.end + 20 && frame.t <= run.end + 150,
});
// Within 4 px everywhere: the marker and the controls are read at whole
// px, so each read adds up to a px.
expect(read.worst, JSON.stringify(read)).toBeLessThanOrEqual(4);
expect(
read.worst,
`the frames miss the call, started at a frame after the block from the value and the velocity on screen there, by ${read.worst.toFixed(1)} px (at most 4 px): ${JSON.stringify(read)}`,

@astracat-bot astracat-bot Bot Nov 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking: toFixed(1) prints the 4.02 px miss from the description as "by 4.0 px (at most 4 px)", which reads as a pass while the check fails; only the JSON after it shows 4.02. Two decimals keep the words honest:

`the frames miss the call, started at a frame after the block from the value and the velocity on screen there, by ${read.worst.toFixed(2)} px (at most 4 px): ${JSON.stringify(read)}`,

).toBeLessThanOrEqual(4);
// The call's own clock misses the same frames by far more, so the case
// tells the two apart.
expect(read.skip, JSON.stringify(read)).toBeGreaterThan(20);
expect(
read.skip,
`the call's own clock fits the same frames within ${read.skip.toFixed(1)} px, so the case cannot tell the two apart (it needs over 20 px): ${JSON.stringify(read)}`,
).toBeGreaterThan(20);
});
}

Expand Down
Loading