Skip to content

fix(graph): widen the flow-speed slider range and stop at zero in the compat engine - #180

Open
Coding-Dev-Tools wants to merge 1 commit into
mainfrom
ship/flow-speed-range-widen
Open

fix(graph): widen the flow-speed slider range and stop at zero in the compat engine#180
Coding-Dev-Tools wants to merge 1 commit into
mainfrom
ship/flow-speed-range-widen

Conversation

@Coding-Dev-Tools

Copy link
Copy Markdown
Owner

fix(graph): widen the flow-speed slider range and stop at zero in the compat engine

Two real bugs in the compat engine's flow-speed rendering:

  1. At flowSpeed=0 the engine kept rendering particles at a residual
    speed (0.002 + 0 = 0.002), so the slider visibly did nothing at the
    low end — the particles just slowed to a crawl. The every-node engine
    already enforced a "moving = speed > 0" guard; the compat engine did
    not. Now flowActive is true iff flowSpeed > 0; when false, the
    per-link particle count drops to 0 AND the per-link speed callback
    returns 0 (full stop).

  2. The active range was 0.002 + (flowSpeed/100)*0.008 = 0.002..0.01
    (a 5x range). The every-node engine's comparable range is 24x; the
    compat engine is brought into line at ~34x by widening to
    0.0005 + (flowSpeed/100)*0.025 = 0.00075..0.0255.

A new regression test
test_flow_speed_slider_has_a_visible_range_in_compat_engine snapshots
the per-link speed closure at flowSpeed 0/1/50/100 and asserts the
range is wide (>=10x) and monotonic, and the stop-at-zero returns 0.

Bench: 292 dashboard+graph engine tests pass.

… compat engine

Two real bugs in the compat engine's flow-speed rendering:

1. At flowSpeed=0 the engine kept rendering particles at a residual
   speed (0.002 + 0 = 0.002), so the slider visibly did nothing at the
   low end — the particles just slowed to a crawl. The every-node engine
   already enforced a "moving = speed > 0" guard; the compat engine did
   not. Now flowActive is true iff flowSpeed > 0; when false, the
   per-link particle count drops to 0 AND the per-link speed callback
   returns 0 (full stop).

2. The active range was `0.002 + (flowSpeed/100)*0.008` = 0.002..0.01
   (a 5x range). The every-node engine's comparable range is 24x; the
   compat engine is brought into line at ~34x by widening to
   `0.0005 + (flowSpeed/100)*0.025` = 0.00075..0.0255.

A new regression test
`test_flow_speed_slider_has_a_visible_range_in_compat_engine` snapshots
the per-link speed closure at flowSpeed 0/1/50/100 and asserts the
range is wide (>=10x) and monotonic, and the stop-at-zero returns 0.

Bench: 292 dashboard+graph engine tests pass.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8bbf8bd497

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

/* Widened from `0.002 + (flowSpeed/100)*0.008` (a 5x range, 0.002..0.01) to
`0.0005 + (flowSpeed/100)*0.025` (a ~34x range, 0.00075..0.0255) so the slider
is visibly responsive end-to-end. */
.linkDirectionalParticleSpeed(l => flowActive ? (0.0005 + (flowSpeed / 100) * 0.025) : 0);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Preserve the default speed when flowSpeed is unset

When a standalone caller uses the exported EngraphisGraph.create() API and calls setData() without first supplying flowSpeed, the initial settings at engraphis-graph.js:7357-7365 leave it undefined. flowActive then defaults to true, but this callback computes with NaN, so active links receive three particles with an unusable particle speed instead of the previous default based on 45. Use a finite fallback speed before both the activity check and speed calculation.

Useful? React with 👍 / 👎.

Comment on lines +9328 to +9333
const flowActive = Number.isFinite(flowSpeed) ? flowSpeed > 0 : true;
const flowing = !fullGraph
&& state.settings.flow !== false
&& motion
&& !reducedMotion
&& flowActive

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Stop flow only at the slider's visible zero endpoint

In the dashboard, visible slider values 1 through 22 are transformed to an engine value of 0 by ledger.js:2453-2462, because the 2x response is centered at 45 and clamped at the minimum. This new guard therefore removes particles throughout roughly the lower quarter of the control, not just when the user selects zero, making that portion of the slider inert. The zero-stop decision needs to preserve the visible endpoint separately or avoid applying the centered response mapping to flow speed.

Useful? React with 👍 / 👎.

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

Successfully merging this pull request may close these issues.

1 participant