Skip to content

Share one visible-vertex computation and scope canvas icons to drawn types - #2120

Closed
kmcginnes wants to merge 1 commit into
resolve-style-data-per-typefrom
scope-canvas-icons-to-drawn-types
Closed

Share one visible-vertex computation and scope canvas icons to drawn types#2120
kmcginnes wants to merge 1 commit into
resolve-style-data-per-typefrom
scope-canvas-icons-to-drawn-types

Conversation

@kmcginnes

Copy link
Copy Markdown
Collaborator

Description

Two related fixes to how much work a render does.

The vertex pipeline ran twice per render. GraphViewer calls useRenderedVertices() directly and useRenderedEdges(), which called useRenderedVertices() internally to build its set of valid endpoints. Every hook has its own render-scoped memo, so the whole pipeline — icon resolution included — ran once per call site. The filter predicate is now a derived atom both pipelines read, so the store computes it once.

Canvas style and icon resolution covered every type in the schema. useBackgroundImageMap(useAllVertexStyles()) iterated all of them on every render. On the stress schema that is 10,044 vertex types resolved to draw 3. canvasVertexStylesAtom scopes it to the types actually on the canvas. The schema view keeps useAllVertexStyles, since drawing every type is its job.

Measurement

Chrome DevTools against a live 10k-type Neptune schema, expanding a 244-neighbour airport with limit 75 (76 nodes / 150 edges). Matched 10s windows from the click, ~81k samples each:

self time in window before after this PR after scoping (this PR)
useBackgroundImageMap 59.7ms ~29ms 0.0ms
style work in renderedEntities 5.2ms ~0.7ms ~0.3ms

The 59.7 → 29ms halving is the double-call fix, and matches the predicted 50% exactly. The drop to 0.0ms is the scoping — the function no longer appears in the profile at all.

What this does not fix. Total busy JS and INP were within run-to-run noise, and the dominant expansion cost remains cytoscape rendering plus the fcose layout (~390-470ms long task), which this does not touch. This removes schema-scale style work from the render path; it is not a fix for the reported expansion choppiness.

How to read

  1. renderedEntities.tsvisibleVertexIdsAtom and canvasVertexStylesAtom.
  2. displayVertex.ts — one selector exported so the atoms can read it.

Note

The comment on visibleVertexIdsAtom records that it still recomputes on a style change, because displayVerticesInCanvasSelector resolves display labels through the style atoms. Decoupling that is tracked in #2116.

Stack

Both atoms are fused into one in fuse-canvas-vertex-passes later in this stack.

…types

`useRenderedEdges` called `useRenderedVertices()` while `GraphViewer` also called
it directly, so the whole vertex pipeline — icon resolution included — ran twice
per render. The filter predicate is now a derived atom both pipelines read, so
the store computes it once.

Canvas style and icon resolution is scoped to the vertex types actually drawn
rather than every type in the schema: the stress schema carries 10,044 vertex
types to draw 3, and resolving all of them each render was the dominant
app-side render cost. The schema view keeps `useAllVertexStyles`, since drawing
every type is its job.

Measured over matched 10s windows on a live 10k-type schema, expanding a node:
`useBackgroundImageMap` self time 59.7ms -> ~29ms, style work in
`renderedEntities` 5.2ms -> ~0.7ms. Total busy time and INP were within
run-to-run noise; the dominant expansion cost remains cytoscape rendering and
the fcose layout, which this does not touch.
@kmcginnes

Copy link
Copy Markdown
Collaborator Author

Superseded by #2128, which consolidates this stack into a single PR targeting #2112. Same commits, same end state — the branch there is byte-identical to the tree these were cut from, rebased onto schema-view-style-perf after #2118 was squash-merged into it.

@kmcginnes
kmcginnes deleted the branch resolve-style-data-per-type August 14, 2026 21:11
@kmcginnes kmcginnes closed this Aug 14, 2026
@kmcginnes
kmcginnes deleted the scope-canvas-icons-to-drawn-types branch August 14, 2026 21:11
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