MultiWaySyntenyDisplay

Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release — see pluggable elements for concepts. Provided by the linear-comparative-view plugin. View source.

draws a multi-genome ortholog track (an adapter whose features carry a mate per other assembly, e.g. MCScanBlocksAdapter) as one lane per assembly inside a plain linear genome view. The top lane is the view's own assembly at genomic coordinates; every other lane is laid out in its own local coordinate frame fitted to the viewport — non-anchored, the same move the multi-sample variant matrix makes — with ribbons connecting each gene's placements between adjacent lanes. The ribbons ride the pairwise synteny display's GPU passes and the lanes the feature track's, with Canvas2D and the SVG export drawing the same cells.

The configuration slots for this model are documented on its config schema page.

Members a composed model contributes are listed here too, so these tables are the whole surface.

Properties

Member	Description	Defined by
type `type: types.literal('MultiWaySyntenyDisplay')`		MultiWaySyntenyDisplay
configuration `configuration: ConfigurationReference(configSchema)`		MultiWaySyntenyDisplay
laneFilter `laneFilter: types.frozen<LaneFilter \| undefined>()`	the reader's lanes, by assembly name: `only` the ones the picker ticked, or the lanes in force `except` the ones Hide lane took out. Undefined is `configuredLanes`, or every lane where there are none. Session state rather than adapter config: a choice made in front of this picture, which a shared session carries	MultiWaySyntenyDisplay
id `id: ElementId`		BaseDisplay

Volatiles

Member	Description	Defined by
fetchedFeatures `fetchedFeatures: undefined as \| { anchor: string; features: Feature[] } \| undefined`	the ortholog fetch's answer beside the anchor assembly it asked for	MultiWaySyntenyDisplay
seenAttributeRanges `seenAttributeRanges: {} as Record<string, AttributeRange>`	per ribbon channel, the span or labels every fetch since the ribbon mode was picked has carried, labels in first-seen order; see `ribbonAttributeRanges`	MultiWaySyntenyDisplay
laneGenes `laneGenes: undefined as Map<string, HeldLaneGenes> \| undefined`	per lane, the gene models fetched from that assembly's own gene track, so a lane draws real exon structure at that genome's coordinates, and the region key they were fetched under — the lane fetch's committed stamp, which its gate compares and `dataSuperseded` reads per lane. Merged a lane at a time: a pan that moves one lane's quantized window refetches that lane and leaves the others' genes as they were	MultiWaySyntenyDisplay
laneGenesCoverMatesFor `laneGenesCoverMatesFor: undefined as string \| undefined`	the anchor assembly under which a lane-gene commit has covered a MATE lane. The anchor's spec exists as soon as the view does, so the first commit can be the anchor alone, before the ortholog fetch has given any mate a frame; the lanes' first real filling is the commit after that, and it is the one a capture has to wait for. Keyed by anchor so a re-anchor onto another genome waits again	MultiWaySyntenyDisplay
laneLinks `laneLinks: undefined as Map<string, HeldLaneLinks> \| undefined`	alignments between ADJACENT mate lanes, fetched per pair from the same track when the source is an alignment file naming no star anchor — the direct records the file holds for that pair, at the lanes' own coordinates — each beside the region key it was fetched under, merged per pair	MultiWaySyntenyDisplay
declaredLanes `declaredLanes: undefined as DeclaredLane[] \| undefined`	the lanes the source's header declares, read once with the tier info; undefined until the header lands or when the adapter is one whose header is never asked for	MultiWaySyntenyDisplay
starAnchor `starAnchor: undefined as string \| undefined`	the anchor a star source announces in its header. A star of pairwise alignments holds no mate-vs-mate rows, so its adjacent pairs' links are composed through the anchor rather than asked for	MultiWaySyntenyDisplay
hoverTarget `hoverTarget: undefined as HoverTarget \| undefined`	the glyph, box or ribbon under the pointer — what a click opens and the tooltip names	MultiWaySyntenyDisplay
clickedTarget `clickedTarget: undefined as \| { groupKey?: string; targetIdx?: number } \| undefined`	clicked twin of the hover: the group or direct-link ribbon whose outline stays after the pointer leaves it, cleared by a click on empty canvas or a refetch	MultiWaySyntenyDisplay
laneDecisions `laneDecisions: new Map<string, LaneDecision \| undefined>()`	what the last settle decided per mate lane — contig, orientation, rung and where the lane is pinned to the anchor. Made once per settled block set by the installer in afterAttach, holding each choice until the evidence clearly moves; the frames the lanes draw in are derived from these against the live view	MultiWaySyntenyDisplay
pinnedLaneContigs `pinnedLaneContigs: new Map<string, string>()`	the contig the reader pinned a lane onto from its header menu, which outranks the lane's own vote while the window still places anything on it. Volatile like the decisions it steers: a pin is a choice about this window, and the lane falls back to choosing once the pinned contig explains nothing here	MultiWaySyntenyDisplay
pinnedLaneFlips `pinnedLaneFlips: new Map<string, LaneFlipPin>()`	the orientation the reader pinned a lane to from its header menu, which outranks the lane's own vote while it draws the contig the pin was set on. A commit of another anchor's features drops them all: the pins are stated against the anchor's order	MultiWaySyntenyDisplay
renderOriginPx `renderOriginPx: 0`	the view's scroll offset the stack is laid out against, refreshed with the decisions. Between refreshes a pan is one translate of the whole stack (`dragOffsetPx`), not a relayout of every lane	MultiWaySyntenyDisplay
laneTransitions `laneTransitions: new Map<string, LaneTransition>()`	per mate lane re-decided onto the contig it already drew, the move from where it drew to its new frame; see `laneTransitionsAfter`. A transition is dropped once the clock passes its end	MultiWaySyntenyDisplay
laneMotionClockMs `laneMotionClockMs: 0`	the wall clock the last drawn frame of a transition read, advanced by the component's frame loop	MultiWaySyntenyDisplay
error `error: undefined as unknown`		BaseDisplay
statusMessage `statusMessage: undefined as string \| undefined`		BaseDisplay
statusProgress `statusProgress: undefined as number \| undefined`	determinate progress fraction [0,1] for the current status, or undefined when the in-flight phase is indeterminate. Set alongside `statusMessage` by `setStatusMessage`; a display that never shows a bar simply leaves it undefined.	BaseDisplay
scrollTop `scrollTop: 0`		TrackHeightMixin
forceLoadTrack `forceLoadTrack: false`	The force-load button's track-wide approval. Volatile so it never reaches a saved session; the `forceLoad` config slot is the durable form.	RegionTooLargeMixin
byteEstimate `byteEstimate: undefined as ByteEstimate \| undefined`	The last byte measurement: bytes, the span they were taken at, and whether zooming has been shown not to shrink them. Survives `clearAllRpcData`; dropped on chromosome navigation and on a tier swap.	RegionTooLargeMixin
gateMeasuredViewportKey `gateMeasuredViewportKey: undefined as unknown`	The `gateViewport` key the gate last asked the adapter about, on either axis — the viewport AND the settings it asked under. Separate from `byteEstimate` because a density refusal measures no bytes.	RegionTooLargeMixin
canvasDrawn `canvasDrawn: false`	flips true on first paint; read by test selectors to detect render	RenderLifecycleMixin
paintCount `paintCount: 0`	bumped after every frame the backend painted, so a consumer that reads this display's canvas — the circular view's ring, which copies the strip into a texture — knows when the pixels moved	RenderLifecycleMixin
currentRenderingBackend `currentRenderingBackend: undefined`	current backend reference, updated on context-loss recovery. Typed `unknown` (not generic `B`) on purpose: this mixin is composed by every display via a non-generic factory, so the per-display backend type `B` isn't known here — it's supplied at `attachRenderingBackend<B>` and narrowed with `as B` inside the autoruns. Don't "fix" the cast.	RenderLifecycleMixin
renderTick `renderTick: 0`	counter the render autorun observes; bumped to force a re-render	RenderLifecycleMixin
autorunsInstalled `autorunsInstalled: false`	guards attachRenderingBackend so the autorun pair spawns once per instance	RenderLifecycleMixin
renderError `renderError: undefined`	the render-backend (GPU/Canvas2D init or context-loss) error, or undefined. Single source of truth for the render-error terminal state: `useRenderingBackend` writes it from the canvas-init mechanism so the model — not React-local hook state — owns every terminal state. Read by `displayPhase` (whose `renderError` term outranks `loading`, suppressing the scrim) and by `DisplayChrome` (shows the retry overlay).	RenderLifecycleMixin
loadedFetchKey `loadedFetchKey: undefined as FetchKey \| undefined`	`currentFetchKey` as it stood when the held data was committed — the loaded half of the freshness compare. Written only by `commitFetchResult`, so a display cannot stamp data it did not fetch, and cleared by `reload` for the overlay's sake rather than the refetch's (the skeleton's reload epoch is what overrides its gate). The data itself stays display-owned: arc keeps stale arcs on screen under the loading overlay, HiC the stale matrix, synteny the stale ribbons.	KeyedFetchMixin
activeSignal `activeSignal: undefined as AbortSignal \| undefined`	signal of the in-flight fetch, or undefined when idle	FetchMixin
fetchGeneration `fetchGeneration: 0`	bumps at every fetch end; autoruns read it to re-evaluate, and it doubles as the staleness epoch inside runFetch	FetchMixin
reloadCounter `reloadCounter: 0`	Bumped by `reload()` and read unconditionally by the fetch autoruns, so a user retry re-runs the body even where nothing else moved — after an error every other fetch input is unchanged. It is also the half that survives a `reload()` override that forgets to invalidate, which is the dead Retry button `makeRetryContractCheck` reports. Declared here because this is the one mixin every fetch foundation composes, the same argument that put `fetchInert` below; the comparative family carried its own until ADR-105.	FetchMixin
statusWindow `statusWindow: createStatusWindow(writeStatus(self))`	This display's status field, and the only thing that writes it: one throttle window, one slot per concurrent operation, so N parallel per-region fetches thin to one stream between them rather than N and a second operation cannot end the first one's label (ADR-081). Lent whole to `createAbortRotation` by a display that also runs a bare-autorun fetch — see `StatusReporter`.	FetchMixin
fetchCanceled `fetchCanceled: false`	true after the user explicitly cancels a load (the loading overlay's cancel button → `cancelFetchByUser`). A durable, blocking state — unlike `cancelFetch`, it does not retrigger the fetch autoruns — so the load stays stopped until the user retries (`reload`) or the viewport changes. Any new fetch clears it (`runFetch` resets it at the start).	FetchMixin
fetchRotation `fetchRotation: createAbortRotation(self, { statusWindow: self.statusWindow, })`	The latest-wins machine this mixin is a wrapper around, and not a second one: `createAbortRotation` owns abort rotation, the `isCurrent` guard, the status slot and the supersede-versus-end rule (ADR-080, ADR-081), for every fetch in the codebase that has one. `runFetch` adds the observable bookkeeping a display needs on top — `isLoading`, `error`, `fetchGeneration`, `fetchCanceled` — and nothing else. It was two implementations of that machine until 2026-08-20, which is how they came to disagree about whether a completed fetch releases its signal. A display's primary fetch is this wrapper; a second concurrent fetch on the same node holds a rotation of its own, which is why the primitive is the thing that exists and this is the thing built on it (ADR-054 §1, the one section ADR-105 keeps). It is lent this display's `statusWindow`, so the fetch takes a slot on the one field rather than opening a second window over it — the whole point of `StatusReporter`.	FetchMixin
dismissedLegendSections `dismissedLegendSections: [] as string[]`	Ids of the scales whose section the reader closed on its own; cleared when the whole legend is shown again. Volatile where `showLegend` is config: which sections a reader collapsed in one sitting is not how the track is configured.	LegendMixin
lodTierInfo `lodTierInfo: undefined as LodTierInfo \| undefined`		LodTierInfoMixin

Getters

Member	Description	Defined by
lgv `ModelInstanceTypeProps<_OverrideProps<_OverrideProps<…>, { ...; }>> & ... 27 more ... & IStateTreeNode<...>`	the hosting linear genome view. `GlobalFetchMixin` hands down the view-shaped `host` its own gating needs; a display reaching LGV's own geometry names it itself, the way the arc displays do	MultiWaySyntenyDisplay
features `Feature[] \| undefined`	the fetched features while the view is on the anchor they were fetched for; another genome's groups read as absent, so no settle decides a lane from them	MultiWaySyntenyDisplay
hoveredGroupKey `string \| undefined`	the ortholog group under the pointer; every ribbon of that group highlights, so one hover reads the group across all lanes	MultiWaySyntenyDisplay
lodMode `LodMode`	the level-of-detail tier the reader pinned, or 'auto' for the adapter's own bpPerPx threshold. `lodTier` is what resolves it	MultiWaySyntenyDisplay
hasLodCapableAdapter `boolean`	whether the track's adapter has tiered storage to switch between — gates the "Level of detail" menu, the way LGVSyntenyDisplay gates it	MultiWaySyntenyDisplay
lodTier `LodTier`	the tier the ortholog and lane-link fetches ask an indexed PIF for, resolved here on the main thread off the SETTLED zoom and folded into `viewSignature`, so a tier flip refetches and a gesture travelling through the threshold does not. 'fine' at every zoom for an adapter with no tiers, a gene table included	MultiWaySyntenyDisplay
liveLodTier `LodTier`	the same tier off the live zoom, for `dataSuperseded`	MultiWaySyntenyDisplay
canvasWidth `number`		MultiWaySyntenyDisplay
viewSignature `string \| undefined`	staleness axes are the static-block set, same as arc — pan/zoom past a block boundary refetches, a scroll inside the loaded blocks does not — and the level-of-detail tier	MultiWaySyntenyDisplay
groups `MultiWayGroup[]`	anchor-sorted gene groups reconstructed from the pairwise features	MultiWaySyntenyDisplay
featuresAreNameless `boolean`	a gene-level source names its features and groups chain on the names; an alignment-level source (a multi-genome PAF) names nothing, which is what makes the per-pair link fetch worth issuing	MultiWaySyntenyDisplay
ribbonColor `string`		MultiWaySyntenyDisplay
domain `string[]`		MultiWaySyntenyDisplay
ribbonColorField `string`		MultiWaySyntenyDisplay
ribbonColorAttributes `string[]`	the columns the track declares, each offered as its own ribbon mode. From the config rather than the data, so the menu is right before the first fetch	MultiWaySyntenyDisplay
ribbonColorDomain `string[]`	the `ribbonColor.domain` order a text column's labels take. A label's color is its position in that list, so this is the ribbons' order as much as the key's	MultiWaySyntenyDisplay
ribbonAttributeRanges `Record<string, AttributeRange>`	what the ribbon modes paint from: each channel's span, and a text column's labels in `ribbonColorDomain` order	MultiWaySyntenyDisplay
hideUnlabelled `boolean`		MultiWaySyntenyDisplay
drawCurves `boolean`		MultiWaySyntenyDisplay
bridgeSkippedLanes `boolean`		MultiWaySyntenyDisplay
showLaneTicks `boolean`		MultiWaySyntenyDisplay
geneColorSettings `GeneColorSettings`	the `color` object and `utrColor` as written, neither evaluated	MultiWaySyntenyDisplay
geneColorEncoding `string \| FieldColorEncoding \| undefined`	the gene `color` as it paints, through the one resolver every display's colour object goes through	MultiWaySyntenyDisplay
geneColorField `string`	the field the genes paint by, `''` while `color.value` paints	MultiWaySyntenyDisplay
geneColorDomain `readonly string[]`		MultiWaySyntenyDisplay
boxColors `GeneColors`	the placement boxes' fills, off the groups' own records: resolved once per ortholog fetch and colour setting, so a settle runs no jexl	MultiWaySyntenyDisplay
laneGeneColors `ReadonlyMap<string, GeneColors>`	per lane, its genes' fills, resolved once per commit of that lane's genes and colour setting, so a settle or another lane's commit runs no jexl	MultiWaySyntenyDisplay
selectedFeatureId `string \| undefined`		MultiWaySyntenyDisplay
anchorAssemblyName `string`		MultiWaySyntenyDisplay
adapterDeclaresLanes `boolean`	whether the adapter type says its header declares the lane universe (`adapterCapabilities: ['headerLanes']`); an untiered adapter gets a header read only when this is true	MultiWaySyntenyDisplay
configuredLanes `string[]`	the lanes a source declaring its own opens on: the track's assemblies beside the anchor, since a graph naming 464 haplotypes on a track naming eight means those eight. Empty for every other source	MultiWaySyntenyDisplay
laneSelection `readonly string[] \| undefined`	the lanes in force: the picker's choice, else `configuredLanes` where there are any, else undefined for every lane. A hidden lane is still in force, so hiding one refetches nothing	MultiWaySyntenyDisplay
hiddenLanes `readonly string[]`	the lanes Hide lane took out of the drawing	MultiWaySyntenyDisplay
fetchLaneSelection `string[] \| undefined`	the lane selection an ADAPTER is asked to narrow its fetch to, which is not the same thing as the selection the stack draws. A source whose header declares the lane universe knows lanes as objects it can cut on, and is the only kind that can answer for a subset more cheaply than for all of them — `GbzBaseSyntenyAdapter` walks only the named haplotypes from an anchor rather than naming all 464 and discarding. For every other multiway source the term would be a refetch bought for a filter it ignores, so it is withheld and `rowAssemblies` narrows the drawing exactly as before.	MultiWaySyntenyDisplay
anchorAssembly `(ModelInstanceTypeProps<…> & { error: unknown; loadingP: Promise<…> \| undefined; ... 10 more ...; refNameMismatches: Map<…>; } & ... 13 more ... & IStateTreeNode<...>) \| undefined`		MultiWaySyntenyDisplay
anchorLocString `string`	where the anchor lane is looking, off the settled blocks where there are any, so a header reading it does not flicker through a pan	MultiWaySyntenyDisplay
laneUniverse `LaneChoice[]`	every lane the picker can offer: the header's declared lanes in the source's order, then the genomes the track config names, then any lane the fetched window places that neither named, each saying whether the stack draws it. The anchor is never a lane	MultiWaySyntenyDisplay
rowAssemblies `string[]`	mate assemblies densest-first, one lane each below the anchor lane, with any `domain` lanes pinned above them, narrowed to the lanes the stack draws. A paralogy record's mate is the anchor assembly itself; those draw on the anchor's own axis rather than as a lane	MultiWaySyntenyDisplay
canReanchor `boolean`	whether a mate lane can become the anchor. A star source names its one anchor in its header, and a source declaring its lanes without the view's anchor among them answers from that anchor alone; either re-anchored on a mate draws next to nothing	MultiWaySyntenyDisplay
visibleBpSpan `number`		MultiWaySyntenyDisplay
visibleGroupWindows `{ group: MultiWayGroup; start: number; end: number; }[]`	the groups whose anchor placement is inside the settled viewport, each with the bp interval of it the viewport shows: the hull of the settled blocks the group meets, so a group reaching across a block boundary is cut at neither	MultiWaySyntenyDisplay
visibleGroups `MultiWayGroup[]`	the groups the viewport shows something of, WHOLE: what the picture is drawn from, since the stack is translated between settles and a group cut at the viewport edge would end mid-ribbon on the first pan	MultiWaySyntenyDisplay
fitGroups `MultiWayGroup[]`	the same groups cut to the viewport — the population every lane's local frame is fitted to, so panning the anchor re-lays-out the other lanes. Cut rather than merely filtered because the fetch is padded and the records come back cut to the PADDING: see `clipGroupToAnchor`	MultiWaySyntenyDisplay
tickIntervalBp `number`	the one bp interval every lane draws its ticks at, so tick spacing is readable as bp-per-pixel across lanes drawn in different frames	MultiWaySyntenyDisplay
scrollContentHeight `number`	the stack's full drawn height: the track height until a lane would fall under the minimum pitch, then fixed-pitch and taller than the viewport — what the scrollbar is sized against	MultiWaySyntenyDisplay
laneGeneAdapters `Map<string, Record<string, unknown>>`	per lane, the session's best-ranked annotation track declared for that assembly alone (`annotationRank`). Ranked rather than first found, since a config routinely puts `hg38-rmsk` in BED beside `hg38-genes` in GFF3. One pass over the tracks against the lanes' canonical names, so a cohort of lanes costs no more than one	MultiWaySyntenyDisplay
scrollViewportHeight `number`		MultiWaySyntenyDisplay
anchorPlacements `Map<string, AxisPlacement>`	where the view draws each visible group's anchor interval, in the view's px before the scroll offset and in the anchor's own direction — start end first, so a horizontally flipped view hands the ribbons the crossed pair it is drawing — with the clipped interval's centre as the coordinate a lane decision can pin to. The view's own `bpToPx` through `axisPlacement`, which is the only honest answer: it is piecewise over the displayed regions and no `RowFrame` can stand in for it. Read both by the lane-alignment seed and by the anchor lane's own ribbons, so "the lanes line up against where the anchor actually draws" holds by construction rather than by two loops agreeing	MultiWaySyntenyDisplay
dragOffsetPx `number`	how far the view has scrolled since the stack was laid out: the one live read a pan makes, applied as a translate over the whole stack	MultiWaySyntenyDisplay
anchorReversed `boolean`	the anchor axis reads right to left: a horizontally flipped view. A lane's decision is stated against the anchor's order, so this mirrors every lane with the anchor without a re-decision	MultiWaySyntenyDisplay
anchorSpans `Map<string, Span>`	the anchor placements in the stack's own px: what the anchor lane draws and what every ribbon out of it starts from	MultiWaySyntenyDisplay
anchorAbsX `Map<string, { coord: AnchorCoord; x: number; }>`	the first link of the alignment chain: each visible group's anchor centre and the view's px for it BEFORE the scroll offset, so a settle decision reading this does not re-run on every pan	MultiWaySyntenyDisplay
rowFrames `Map<string, RowFrame \| undefined>`	each mate lane's local coordinate frame: the settle's decision against where the view draws its pivot now, carrying the frames a running transition moves it from	MultiWaySyntenyDisplay
laneGenesFetchSpecs `LaneGenesFetchSpec[]`	what the lane-genes autorun fetches: one spec per lane with a gene track, over the quantized window each lane's frame slides in	MultiWaySyntenyDisplay
laneLinksFetchSpecs `LaneLinksFetchSpec[]`	one spec per ADJACENT mate-lane pair when the source is an alignment file naming no star anchor: the upper lane's window queried against the lower lane's assembly at the settled tier, which a multi-genome adapter answers with the direct records it holds for that pair — none, for a star that did not name its anchor. None for a source that announced itself a star, which holds no such rows. Only pairs the session holds both assemblies of: the fetch renames its region through the assembly manager, which refuses a PanSN sample the config never declared, and a multi-genome file routinely carries more of those than the config names	MultiWaySyntenyDisplay
laneStack `LaneStack`	the stack the picture is drawn from: one `Lane` per assembly, plus the geometry every layer places against. Every layer — bands, ticks, ribbons, glyphs, boxes, headers, the hover outline — is a walk over this, and the on-screen body and the SVG export walk the same one. The lane genes are not in it: only the glyph cells read them, and a stack that carried them re-uploaded every ribbon and tick, and dropped the hover, on every gene commit	MultiWaySyntenyDisplay
laneMaps `ReadonlyMap<number, LaneMap>`	by lane row, where each moving lane draws its cells at the frame loop's clock: both frames re-derived against the live view, so a pan or zoom mid-flight composes with the move	MultiWaySyntenyDisplay
laneHeaderRows `LaneHeaderRow[]`	what each lane's header says and where, for the on-screen headers and the export's captions alike	MultiWaySyntenyDisplay
pairLinks `ReadonlyMap<string, { links: Feature[]; }>`	the direct records between each adjacent mate-lane pair as the ribbons read them: the pair's fetched links where the file holds any, else the links composed through the anchor from the groups, one record per placement either lane makes. Off the fetched sets and the session's assemblies, never the frames, so a settle recomposes nothing	MultiWaySyntenyDisplay
ribbonGeometry `RibbonGeometry`	the ribbons between each adjacent lane pair as the synteny passes' instance data, in the stack's own px, plus what each ribbon opens	MultiWaySyntenyDisplay
tickGeometry `TickGeometry`		MultiWaySyntenyDisplay
bandCell `MultiWayCell`	the opaque bands under the mate lanes, off the lane geometry rather than the stack: the stack moves on every pan and settle, the bands only when a lane comes or goes, and an unchanged cell uploads nothing	MultiWaySyntenyDisplay
laneGlyphCells `Map<string, MultiWayCell>`	two cells per lane — its gene models and baseline, and its placement boxes; see `buildLaneCells`. Boxes first, so a hit test walking these in order answers the box over the gene the way the draw order does. Fills come off `laneGeneColors` and `boxColors`, so a settle re-runs no jexl slot, and neither the hover nor the selection reads these: the chrome draws both. A lane whose `Lane`, fills and ink are the ones its cells were packed from keeps those cells, so another lane's gene commit re-uploads nothing of it	MultiWaySyntenyDisplay
geneColorScales `ColorScale[]`	The key for the glyph colors, read off the anchor lane: it is the one lane whose color for a group runs down every chain the stack draws, and keying every lane instead would spend a row on each strain's private genes and blow the bound on the window where the chains are the point. A field keys the values it painted, a `jexl:` color its drawn colors by name, and a constant nothing. `MAX_LEGEND_ENTRIES` rather than `legendIsReadable`'s own default, because this is a derived key and that is the bound a derived key stops being one at. Over the settled window, not the live one: the cells are laid out against `renderOriginPx`, and the decision autorun restamps that at settle, so reading `dragOffsetPx` here only rebuilt the key on every pan frame.	MultiWaySyntenyDisplay
pinnedGeneColorDomain `string[]`	`color.domain` followed by the values the gene key lists that it does not, in the key's order and less the no-value row	MultiWaySyntenyDisplay
colorScales `ColorScale[]`	`LegendMixin`'s hook: the two color vocabularies as their own scales, so each is titled and dismissed on its own, and neither claims the other's colors. The colors here are the config's to encode, and a track that paints one flat color has nothing for a key to say.	MultiWaySyntenyDisplay
namedCells `ReadonlyMap<string, MultiWayCell>`	everything the backend holds bytes for, keyed so an unchanged cell keeps its identity across a rebuild of the map and uploads nothing	MultiWaySyntenyDisplay
namedLayers `MultiWayLayer[]`	the stack back to front: bands under everything, since they exist to cover the view's gridlines; ribbons; each lane's ticks; each lane's glyphs over its own ribbons	MultiWaySyntenyDisplay
hoveredFeatureId `number`	the ribbon feature id the passes highlight: every ribbon of the hovered group shares one, so a hover over any gutter lights the group in all of them	MultiWaySyntenyDisplay
clickedFeatureId `number`	the clicked twin, resolved the same way — a group key survives a relayout, a direct-link index only its own fetch	MultiWaySyntenyDisplay
hoverInk `HighlightRect[]`	The hovered group's placement in every lane that places it, for the chrome's highlight. A ribbon joins ADJACENT lanes only, so a group the middle lane does not place would light nothing there without this.	MultiWaySyntenyDisplay
selectionInk `HighlightRect[]`	Every gene or placement box drawing the selected feature, for the chrome's highlight — off the hit boxes the hit test reads, so what lights is what a click there would select.	MultiWaySyntenyDisplay
highlightStyle `HighlightStyle`	A wash and a border: the glyph colours are the data.	MultiWaySyntenyDisplay
outlineCells `ReadonlyMap<string, MultiWayCell>`	the clicked group's outline in every gutter that draws it — its own cell beside the gutter's, so a selection re-uploads the records the outline traces rather than the gutter's whole buffer, and a pan re-uploads nothing. Ticks are left out: no tick carries a feature id	MultiWaySyntenyDisplay
renderCells `ReadonlyMap<number, MultiWayCell>`	everything the backend holds bytes for, under the numeric region key a block names. Merged from cached maps, so a lane relayout that leaves a gutter's cell alone re-uploads nothing of it	MultiWaySyntenyDisplay
renderLayers `ReadonlyMap<number, MultiWayLayer>`	the stack back to front under those same keys, each gutter's outline layer immediately over the gutter it traces	MultiWaySyntenyDisplay
ribbonRegions `ReadonlyMap<number, SyntenyInstanceData>`	the gutters' ribbon geometry, in draw order — what the pick walks	MultiWaySyntenyDisplay
renderState `MultiWayRenderState`	what a frame draws with: the cells' layout and the live transforms, the drag and each moving lane's map	MultiWaySyntenyDisplay
renderBlocks `RenderBlock[]`	one block per layer, in the order the stack draws them	MultiWaySyntenyDisplay
ribbonPickState `SyntenyRenderState`	the render state as the synteny pick engine reads it: a numeric key per gutter, topmost last, so a point over two gutters answers the one drawn over	MultiWaySyntenyDisplay
animating `boolean`	a lane is moving between two frames, which the chrome publishes for the capture waits. Its cells are culled to both frames meanwhile, so `dataSuperseded` holds the export for it too; the deadline installed in afterAttach drops every transition at its end, so neither latches	MultiWaySyntenyDisplay
awaitingDependentData `boolean`	`FetchMixin`'s hook: the dependent fetches are part of loading until they FIRST land, so an export or a capture never lands between the ortholog fetch and the gene models that fill the lanes. Not for later refetches: those run over lanes that are already drawn, and holding the phase at loading puts the striped scrim over them. A failed lane fetch commits an empty result rather than hanging this (see afterAttach). The first landing is the first one that names a mate lane, not the anchor-only commit that can precede it: the anchor's spec exists before the ortholog fetch has framed any mate, so a phase that read `ready` off that commit let a capture shoot placement boxes while seven lanes were still downloading their indexes (the primate amylase figure, 2026-09-02)	MultiWaySyntenyDisplay
dataSuperseded `boolean`	`GlobalFetchMixin`'s hook: a lane fetch is out, or some lane holds a result fetched under a key its frame has moved past, so the ortholog data the signature calls current is about to be redrawn over; or the live zoom has left the settled tier the held data was fetched at. Holds the export, where the phase above holds only the first landing's scrim. A lane fetch always commits — one failed lane is stamped with an empty result (see afterAttach) — so this cannot latch	MultiWaySyntenyDisplay
hoveredFeature `Feature \| undefined`	`BaseDisplay`'s hook, what the view publishes to `session.hovered`	MultiWaySyntenyDisplay
parentTrack `AbstractTrackModel`		BaseDisplay
RenderingComponent `FC<…>`		BaseDisplay
DisplayBlurb `FC<{ model: ModelInstanceTypeProps<{ id: IOptionalIType<ISimpleType<string>, [undefined]>; type: ISimpleType<string>; }> & { ...; } & { ...; } & IStateTreeNode<...>; }> \| null`		BaseDisplay
adapterConfig `Record<string, unknown>`		BaseDisplay
isMinimized `boolean`	Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible.	BaseDisplay
featureNoun `string`	Overridable hook (default `'feature'`): the SINGULAR word for one of the things this display draws, as a menu row or a chip says it — "Hide this read", "Showing 3 variants". Declared here for the same reason as `hoveredFeature` above: it is read across the display boundary, by chrome that has no idea which display it is drawing for (`SoloSelectionChip`, alignments' group-label overlay), and a name only the base declares is a name every such consumer can rely on. Two displays declared it independently and one of those declarations WAS this default. A control keeps the generic word; content takes this one. "Variant height" reads as a different setting from "Feature height" when it is the same one, so the shared menus stay on "feature" however the display answers here, and the noun varies where it names what the user is looking at — "Showing 3 variants", "Hide this read". A display drawing something the generic word already fits is right to leave this alone. Distinct from the per-hit noun a context menu takes off the clicked item's own `type` ("mRNA", "gene"); that names one annotation, this names what the track holds. The hit noun falls back to this.	BaseDisplay
featureWidgetType `{ type: string; id: string; }`	The widget `openFeatureWidget` opens for one of this display's features. Displays may override it. The default is the generic feature widget, for displays drawing plain features. Displays whose features are a specific kind (a read, a variant, a synteny block) override it, including the `id`: two displays naming one id share the drawer panel, which suits two displays showing the same kind of feature.	BaseDisplay
height `number`		TrackHeightMixin
resizing `boolean`	True for the duration of a height drag on this track, whichever handle is running it. A display whose row geometry is a function of the track height restretches every row per animation frame, and can use this to sit an expensive per-frame layer out of the drag (MAF's dense per-base letter overlay is a Canvas2D pass that scales with rows x columns). The flag itself is the track's (`BaseTrackModel`), so the view brackets a drag without needing the active display to have opted into this mixin. This getter reads it so that a display that did opt in has `self.resizing`.	TrackHeightMixin
scrollableHeight `number`	How far the content scrolls. A sub-pixel overflow is 0: a fit mode that divides the viewport across n rows multiplies back to a few ULPs over it, and an extent of 1e-14px still draws a scrollbar and holds the wheel away from the page.	TrackHeightMixin
host `RegionHost`	The hosting view as the `RegionHost` contract — see `containingHost` for the cast it owns, why the name is `host` and not `view`, and why both foundations still declare the name over one body.	GlobalFetchMixin
staticBlockSignature `string \| undefined`	The static-block set as a signature, or `undefined` before the view is measured — the building block every `viewSignature` in this family starts from. Arc and multi-way synteny are exactly this; HiC appends its resolution. Declared here so the initialized gate is spelled once.	GlobalFetchMixin
dynamicBlockSignature `string \| undefined`	The same over `dynamicBlocks`, for a display whose fetch window is the live viewport rather than the snapped block set (LD).	GlobalFetchMixin
viewportEmpty `boolean`	No content block is on screen, so this display has nothing to fetch and nothing to paint — see `viewportEmpty.ts` for the one viewport that reaches it, how narrow that is, and why the state still has to be terminal rather than a permanent scrim. Both foundations declare it over that one expression, the same way they each declare `host` and `paintInert`.	GlobalFetchMixin
canRender `boolean`	Overrides `RenderLifecycleMixin`'s default-true hook with the LGV precondition both foundations share — see `foundationCanRender`.	GlobalFetchMixin
rendersCanvas `boolean`	Fills `RenderLifecycleMixin`'s hook off `fetchInert`: a display that will never fetch here shows a placeholder where its canvas would be, so `painted` and the pre-first-paint scrim term stop waiting on a paint that cannot come. Sequence and LD each carried this as a second override beside `fetchInert`, always its negation.	GlobalFetchMixin
paintInert `boolean`	Fills `RenderLifecycleMixin`'s `paintInert` hook — see there for why a failed fetch has to read as finished to the consumers outside the display, and `foundationPaintInert` for the second such state and why both fetch families answer it through one function. Overridable, as the hook is: a display with a third inert state of its own says so here.	GlobalFetchMixin
svgReady `boolean`	Policy single-sourced in `computeSvgReady`; this family supplies only the freshness half, which `foundationSvgReady` reads as `dataCurrent` or the vacuous currency of `viewportEmpty`. Note it requires the dataset to actually be current, NOT merely "not currently fetching": the fetch trigger is a debounced `afterAttach` autorun, so at export time `isLoading` can still be false with no data yet — a `displayPhase !== 'loading'` test would then capture an empty render. Never gates on `canvasDrawn`, which an off-screen export never sets. Off-screen renderers gate on it via `awaitSvgReady(model)`.	GlobalFetchMixin
displayPhase `DisplayPhase`	The display's mutually-exclusive visual state, mapped in `foundationDisplayPhase` — every foundation calls it and supplies only its staleness argument, so a term added to `computeActivityPhase` reaches all of them without being wired twice. This family's argument is the constant `true`, deliberately: a global display keeps the last frame up through a refetch (worker output is genomic, so the stale frame draws correctly under the live view transform), so a pan or zoom shows no scrim beyond the `isLoading` window. The pre-first-paint scrim it does want — the gap between mount and `isLoading` going true, which on HiC is the `CoreGetInfo` round trip its first fetch waits on — is `computeActivityPhase`'s shared `rendersCanvas && !canvasDrawn` term, not anything this family spells out. A display with no rendering backend narrows this to the backend-free `DisplayStatusPhase` with `foundationDisplayStatusPhase`, as arc does. Arc cannot reach `renderError`, and the narrower type lets `DisplayStatusChrome` take it with neither a cast nor a dead branch.	GlobalFetchMixin
gateEnabled `boolean`	The opt-in. Overridden with a literal `true` by gated displays, and `check-gated-adapter-budgets` insists on a literal: this mixin returns early on it in an autorun and in `commitFetchBytes`.	RegionTooLargeMixin
byteGateAdapterConfig `Record<string, unknown>`	The adapter config the gate measures — the one at `byteGateAdapterPath`. Overridable for a display whose adapter config is synthesized rather than read off the track.	RegionTooLargeMixin
configuredFetchSizeLimit `number \| undefined`	The display's `fetchSizeLimit` slot, from `regionTooLargeConfigSchemaFields`. `number \| undefined`, because `getConf` answers `undefined` for a slot a composing display's schema never declared and typing it `number` hid the whole failure — `resolveByteLimit` falls back closed, and says why.	RegionTooLargeMixin
densityTooLarge `boolean`	The density axis's verdict, and the whole of that axis's opt-in: `CanvasFeatureGateMixin` overrides it beside the measurement that fills it, and a byte-only display leaves it false.	RegionTooLargeMixin
byteGateAdapterPath `ByteGateAdapterPath`	Where on the track config the measured adapter sits. A tiered display overrides this one hook (MAF: `['adapter', 'summaryAdapter']` while `showSummary`), and both the measurement and the budget follow it.	RegionTooLargeMixin
adapterFetchSizeLimit `number \| undefined`	The measured adapter's own `fetchSizeLimit` slot, read off the live track config rather than the `adapterConfig` snapshot, which omits slots at their default.	RegionTooLargeMixin
configForceLoad `boolean`	The declarative `forceLoad` slot.	RegionTooLargeMixin
gateViewport `GateViewport \| undefined`	What a measurement taken now would be about: the span on screen, and a key for the stretch of genome it covers and the settings it would be taken under. Undefined until the view is measured, and the mixin's only read of the view. Captured before the fetch's round trip, never at commit, so the stamp names the settings the worker actually counted under. The settings term is `settingsFetchInputs`, the axis every family invalidates data on. It belongs in the measurement because the worker's density probe counts ADMITTED features (`densityGate`'s `admit`), so a filter admitting almost nothing is a different measurement of the same viewport — and while staleness was viewport-only, the main thread never went back to ask. The byte axis is an index read no `rpcProps` field can move; the rule is one rule rather than one per axis.	RegionTooLargeMixin
aboveForceLoadFloor `boolean`	Whether the span on screen is at or above `AUTO_FORCE_LOAD_BP`, the one comparison against that constant. False on an unmeasured view.	RegionTooLargeMixin
gateExempt `boolean`	Nothing may gate on either axis: the `forceLoad` slot or the button.	RegionTooLargeMixin
estimatedFetchBytes `number \| undefined`	The stored estimate's bytes; undefined when nothing has been measured.	RegionTooLargeMixin
gateMeasurementStale `boolean`	Whether the last measurement still describes what a fetch issued now would ask: the viewport on screen, under the settings on screen. True before any measurement. The triple's third term, the adapter tier, is not here — a tier swap drops the measurement outright (`ClearByteEstimateOnNavOrTierSwap`) rather than marking it stale.	RegionTooLargeMixin
gateByteLimit `number`	The byte budget: the adapter's limit, else the display's, doubled below `AUTO_FORCE_LOAD_BP`. Read only through `resolvedByteLimit()`.	RegionTooLargeMixin
gateActive `boolean`	Whether the gate may act right now, on any axis: opted in, not exempt, view measured. The view is read last, so an ungated display never touches it.	RegionTooLargeMixin
densityGateActive `boolean`	Whether the density axis may act: `gateActive`, and the span is above the floor — the one axis the floor applies to. Whether it has anything to say is `densityTooLarge`.	RegionTooLargeMixin
tooLargeStatus `RegionTooLargeStatus`	The verdict and its banner text, from the stored estimate against `resolvedByteLimit()` and the density axis when it may act.	RegionTooLargeMixin
regionTooLarge `boolean`		RegionTooLargeMixin
regionTooLargeReason `string`	Banner text for the axis that tripped; empty when not too large.	RegionTooLargeMixin
zoomCanReleaseGate `boolean`	Whether "zoom in to see features" is honest advice. Density always releases on zoom; bytes only if the last zoom-in moved the estimate.	RegionTooLargeMixin
gateSkipsMeasuredViewport `boolean`	The skip both fetch skeletons apply: the banner is up and its measurement already describes the viewport on screen.	RegionTooLargeMixin
paintSuperseded `boolean`	Overridable hook (default false): what is on the canvas was painted from data a later change has made wrong, so `painted` below should answer pending until the repaint lands even though `canvasDrawn` is still true. The per-region fetch foundation fills it with `staleSettingsDrawn` — held data drawn under settings that have since moved — which is the state `clearAllRpcData` used to express by resetting `canvasDrawn` on every settings change, blanking the display to do it. A capture waiting on `data-display-drawn` then waits for the refetch rather than snapshotting the previous setting's pixels. A hook and not a reset of the flag, because the flag is re-marked by any redraw — a pan between the settings change and the refetch would report the stale canvas drawn — and a derivation cannot be raced.	RenderLifecycleMixin
painted `boolean`	The first-paint answer every consumer outside the display should read, `canvasDrawn` being only the raw flag: a display that is deliberately not painting a canvas has finished, and reporting it unfinished leaves every waiter on it waiting forever. The two `rendersCanvas: false` states each had three of their four consumers wired by hand — the loading scrim (`rendersCanvas` / `fetchInert`) and the SVG export (`fetchInert`) — while the fourth, `data-display-drawn`, went on publishing `"false"` forever off the raw flag. That attribute is what `PENDING_DISPLAYS` (`@jbrowse/browser-test-utils`) selects on, so a zoomed-out reference sequence track made every `waitForDisplaysDone` on the page run to its full timeout, and that wait swallows its own timeout without reporting it. `fetchInert` on the comparative side has the same problem: the forgotten reader is the one outside the display, so the display has to publish one name for it. `paintInert` is the third term and the same argument once more, for the state where a display would paint a canvas and never gets to — a fetch that failed before first paint. `paintSuperseded` is the fourth, and the one that subtracts: a canvas painted from data a settings change has made wrong is drawn and not finished. See both hooks.	RenderLifecycleMixin
currentFetchKey `FetchKey \| undefined`	Key of the fetch the current view, settings and adapter call for. The fetch skeleton's freshness key: captured at issue, compared against the stamp above, and written to it at commit. Its identity survives a recomputation onto equal content, so the idle compare is `===`.	KeyedFetchMixin
dataCurrent `boolean`	The shared freshness answer every foundation gives: data has been committed (`loadedFetchKey` is only ever written beside it), it was fetched for the current view and settings, and the display is not about to supersede it itself. A pan inside the loaded blocks stays current; a block entering, a tier step, a settings change or a `reload()` moves one side of the compare. What the fetch autorun gates on is the same compare inside `installFetch`, not this getter — the skeleton owns it so a reload can override it. This one is for the readers outside the fetch, the export gate above all. The per-region twin is `isCacheValid`: what decides a refetch, and deliberately not the whole freshness answer.	KeyedFetchMixin
isLoading `boolean`	true while a fetch is active	FetchMixin
isLoadingOrCanceled `boolean`	`isLoading` widened to cover a user-canceled load: what a hover gate wants, since neither state has a frame on screen that a hit describes. Not a phase input — `computeActivityPhase` reads the two apart, because a cancel is finished (`canceled`) where a fetch is not (`loading`).	FetchMixin
fetchInert `boolean`	Overridable hook (default false): the states where this display deliberately never fetches, so it holds no data and none is coming. Sequence sets it past base resolution ("Zoom in to see sequence"); LD sets it with the triangle toggled off. One hook has three readers. A display that gains such a state declares it once, which covers the reader it would otherwise forget, always the one outside the display: - the phase (`computeActivityPhase`), which otherwise parks a scrim over the placeholder, or a canceled overlay once Cancel is clicked; - the SVG export (`computeSvgReady`'s `extraTerminal`), whose `awaitSvgReady` is an unbounded `when`, so one such display hangs the whole view's export; - the retry contract check (`makeRetryContractCheck`), which would otherwise report a dead Retry on a display correctly declining to load anything. `fetchInert` replaces three hooks: `loadingSuppressed`, `svgReadyExtraTerminal` on each of the two foundations, and `fetchInert` on the comparative family, which had already collapsed them. Both LGV displays that override it returned one expression for all three, and the global family hard-coded one of the three to `false` for a while, so LD could express only half its state. All three fetch families declare it here since the comparative one composed this mixin (ADR-105), so the retry check reads one field everywhere. ADR-082. A hook rather than a `displayPhase` override, because overriding the getter means restating the whole loading condition. Sequence held a verbatim copy of the other terms that way, and a copy misses any term added to the condition later. `fetchInert` lives here because this is the one mixin all three display foundations compose. Same argument, one level down, that put `rendersCanvas` on `RenderLifecycleMixin` beside `canvasDrawn`.	FetchMixin
awaitingPrerequisite `boolean`	Overridable hook (default false), read only by the retry contract check (`makeRetryContractCheck`): "this run declined because a prerequisite fetch in another autorun has not landed, and its arrival wakes this one again". It defers the retry verdict to that later run rather than waiving it, so a display cannot spend its retry on a decline it called preliminary. Two displays set it, one per fetch foundation, so it lives beside `fetchInert` rather than on either: HiC's contacts fetch declines until `CoreGetInfo` lands, and `MultiSampleVariantBaseModel`'s `fetchNeeded` declines until `sourcesBase` does. Both have a `reload()` that wakes the prerequisite's autorun as well as their own. It has to be strictly narrower than the gate it explains. One that restates the gate's negation makes every decline a deferred one. No run is then ever judged, which exempts the display from the check. HiC does this deliberately, because its gate and its prerequisite are one condition; what covers its retry instead is `LinearHicDisplay/infoFetchFailure.test.ts`. Not for a display deliberately not fetching at all — that is `fetchInert` above, which the loading scrim and the export read too.	FetchMixin
settingsFetchInputs `unknown`	The settings axis every fetch family invalidates on: this display's `rpcProps()` payload and its adapter config, as one value compared structurally. The per-region family watches it from `SettingsInvalidate` and stamps it on each region, the keyed families fold it into `currentFetchKey`, and the byte gate measures under it — one getter, so no two can come to invalidate on different axes. `undefined` inside the payload is a real state and a class instance compares by its own fields, which a serialized key could not say; `makeSettingsFetchInputs` has why.	FetchMixin
showLegend `boolean`	Whether the legend is drawn.	LegendMixin
legendTop `number`	Overridable hook (default 0): px the on-screen key is pushed down from its own inset. A display that already draws a control of its own in that corner — Hi-C's resolution box — answers that control's height; the chrome adds its own axis captions on top. The export draws no controls, so it does not read this.	LegendMixin
legendSpec `LegendSpec`	The key, derived from `colorScales` less the sections the reader dismissed. `DisplayChrome` renders it on screen and `renderDisplaySvg` flattens it for the export, so the two describe one set of colors.	LegendMixin
hasLegendKey `boolean`	Whether the display has a key at all. The "Show legend" row is offered only when it does. Overridable for a display whose key is only waiting for data: a scale that stays empty until a region lands must not remove the toggle in the meantime.	LegendMixin

Methods

Member	Description	Defined by
laneKey `(assemblyName: string) => string`	the one spelling two names for the same assembly share	MultiWaySyntenyDisplay
rpcProps `() => { haplotypes: string[] \| undefined; }`	The settings axis of this display's fetch key. A lane selection the adapter acts on changes what comes back, so held data fetched under a different selection is stale and has to be refetched — and the sanctioned way to say so is a field here, which `settingsFetchInputs` folds into `currentFetchKey`, rather than a term hand-folded into `viewSignature`. Reads only user-controlled state (the picker's choice, else the track's config), never anything a fetch produced, which is what the loop trap forbids.	MultiWaySyntenyDisplay
holdsAssembly `(assemblyName: string) => boolean`	whether the session holds a lane's genome under any spelling, which is what a navigation onto it needs and a lane drawn from a blocks table does not	MultiWaySyntenyDisplay
laneFrameOf `(decision: LaneDecision) => RowFrame \| undefined`	the frame a decision draws a lane in, against where the view draws its pivot now; undefined once the pivot is off the displayed regions	MultiWaySyntenyDisplay
pickRibbonAt `(x: number, y: number) => SyntenyPickResult \| undefined`	the ribbon under a container-relative point, topmost first	MultiWaySyntenyDisplay
hitTest `(x: number, y: number) => HoverTarget \| undefined`	what sits under a container-relative point: the glyph or box of the one lane whose glyph row holds it, boxes before genes since that is the order they draw, then a ribbon through the pick engine	MultiWaySyntenyDisplay
trackMenuItems `() => MenuItem[]`	Show..., Color by..., Lanes and Level of detail, then under Launch the same multi-panel launch the view menu and the rubberband offer: every genome aligning to the visible window in a stacked linear synteny view, cut from this track's dataset	MultiWaySyntenyDisplay
renderingProps `() => { displayModel: ModelInstanceTypeProps<{ id: IOptionalIType<…>; type: ISimpleType<string>; }> & { ...; } & { ...; } & { ...; } & IStateTreeNode<...>; }`	props passed to the renderer's React "Rendering" component. these are client-side only and never sent to the worker. includes displayModel and callbacks	BaseDisplay
resolvedByteLimit `() => number \| undefined`	The budget the worker enforces and the banner compares against — the one spelling of that pair. Undefined when the gate may not act.	RegionTooLargeMixin
gateFetchState `() => GateFetchState`	The gate as it stands for a fetch about to be issued. Calling it is the capture, which is why it is a method.	RegionTooLargeMixin
svgLegendWidth `() => number`	Overridable hook (default 0): the width the LGV export reserves beside the plot for this legend. A display whose plot fills its band — the contact matrix, the LD triangle — answers `svgLegendGutterWidth(self)` so the key does not cover it.	LegendMixin

Actions

Member	Description	Defined by
setFeatures `(features: Feature[], anchor?: string) => void`		MultiWaySyntenyDisplay
clearDirectLinkClick `() => void`	a bare targetIdx addresses the outgoing targets array, so it goes whenever the lanes rebuild; a group KEY re-resolves against the rebuilt geometry and stays — load-bearing, since the click's own widget resizes the view and that refetches	MultiWaySyntenyDisplay
setLaneGenes `(fetched: Map<string, HeldLaneGenes>, coversMatesFor: string \| undefined) => void`	`coversMatesFor` is the anchor assembly when this commit framed a mate lane, else undefined	MultiWaySyntenyDisplay
setLaneLinks `(fetched: Map<string, HeldLaneLinks>) => void`		MultiWaySyntenyDisplay
setStarAnchor `(assemblyName: string \| undefined) => void`		MultiWaySyntenyDisplay
pinLaneContig `(assemblyName: string, refName: string \| undefined) => void`	pin a lane onto one of its contigs, or `undefined` to let it choose again. A fresh map, so the decision autorun sees the write	MultiWaySyntenyDisplay
flipLane `(assemblyName: string) => void`	mirror a lane against its current orientation, pinned to the contig it draws	MultiWaySyntenyDisplay
unpinLaneFlip `(assemblyName: string) => void`	let a flipped lane choose its orientation again	MultiWaySyntenyDisplay
setDomain `(domain: string[]) => void`	The whole pinned order; empty is back to densest-first. A caller that saw only some lanes merges first (`mergeDomain`).	MultiWaySyntenyDisplay
setDeclaredLanes `(lanes: DeclaredLane[]) => void`		MultiWaySyntenyDisplay
setSelectedLanes `(names: string[] \| undefined) => void`	draw only `names`, unhiding everything; undefined puts the lanes back to `configuredLanes`, or every lane	MultiWaySyntenyDisplay
setBridgeSkippedLanes `(flag: boolean) => void`		MultiWaySyntenyDisplay
setRibbonColorBy `(field: string) => void`		MultiWaySyntenyDisplay
setRibbonColorDomain `(domain: string[]) => void`		MultiWaySyntenyDisplay
setHideUnlabelled `(flag: boolean) => void`		MultiWaySyntenyDisplay
setDrawCurves `(flag: boolean) => void`		MultiWaySyntenyDisplay
setShowLaneTicks `(flag: boolean) => void`		MultiWaySyntenyDisplay
setLodMode `(mode: LodMode) => void`		MultiWaySyntenyDisplay
chooseLanes `(names: string[]) => void`	the picker's submit: `names` plus the picked lanes no window has offered here, or no choice at all where that is what the lanes come back to	MultiWaySyntenyDisplay
hideLane `(assemblyName: string) => void`	out of the drawing, whatever choice is in force: the lane stays fetched, so this refetches nothing	MultiWaySyntenyDisplay
showLane `(assemblyName: string) => void`	drawn again: unhidden, and added to the lanes in force where they leave it out	MultiWaySyntenyDisplay
showHiddenLanes `() => void`	every hidden lane drawn again, keeping the picker's choice	MultiWaySyntenyDisplay
openLaneSelection `() => void`	the lane picker, over `laneUniverse`	MultiWaySyntenyDisplay
setLaneFrames `(originPx: number, decisions: Map<string, LaneDecision \| undefined>) => void`	a settle's decisions and the offset their px space is anchored at. A lane re-decided on the contig it drew starts moving from where it drew rather than snapping, where motion is allowed	MultiWaySyntenyDisplay
tickLaneMotion `(nowMs: number) => void`	the frame loop's clock; a transition past its end is dropped, which repacks its lane in its settled frame alone	MultiWaySyntenyDisplay
endLaneMotion `() => void`	every lane to its settled frame now	MultiWaySyntenyDisplay
setGeneColorBy `(field: string) => void`	paint the genes by `field`, or by `color.value` for `''`, by display-kit's `colorForField`	MultiWaySyntenyDisplay
pinGeneColorDomain `() => void`	`pinnedGeneColorDomain` into `color.domain`, so every value the gene key lists spends its own range color	MultiWaySyntenyDisplay
selectFeature `(feature: Feature) => void`		MultiWaySyntenyDisplay
openInNewView `(assemblyName: string, loc: string) => void`	a lane's assembly in a linear genome view of its own, at `loc`, with this track along so the new view is the same stack anchored there, and the session's annotation for the genome. Keyed on the display and the lane, so following one lane twice re-navigates the view	MultiWaySyntenyDisplay
reanchor `(assemblyName: string, loc: string) => void`	the hosting view onto `assemblyName` at `loc`; the anchor lane reads off the view's first assembly, so the stack re-anchors on its own, and the outgoing anchor joins a selection in force so it stays drawn	MultiWaySyntenyDisplay
setHoverTarget `(target: HoverTarget \| undefined) => void`		MultiWaySyntenyDisplay
startRenderingBackend `(backend: MultiWayRenderingBackend) => void`	the backend's cells and frame, through the one installer: a cell re-uploads when its identity changes and a frame redraws on anything the render state reads, which on a pan is the drag offset alone	MultiWaySyntenyDisplay
setPointer `(state?: MouseState \| undefined) => void`		MultiWaySyntenyDisplay
clearHoveredFeature `() => void`	`BaseDisplay`'s hook. Two clears call it, because two different things move the lanes under a stationary cursor: the foundation's viewport-change reaction, and this display's own relayout reaction (see afterAttach)	MultiWaySyntenyDisplay
selectHovered `() => void`		MultiWaySyntenyDisplay
renderSvg `(opts?: ExportSvgDisplayOptions \| undefined) => Promise<ReactNode>`		MultiWaySyntenyDisplay
setStatusMessage `(status?: RpcStatus \| undefined) => void`		BaseDisplay
setError `(error?: unknown) => void`		BaseDisplay
reload `() => void`	base display reload does nothing, see specialized displays for details	BaseDisplay
applyDisplaySettings `(settings: Record<string, unknown>, options?: { allowSetters?: boolean \| undefined; } \| undefined) => { applied: string[]; unapplied: UnappliedSetting[]; failed: { ...; }[]; }`	Apply a set of display settings to the live display, and report which were applied. Each key runs through the display config schema's `preProcessSnapshot` (shorthand expansions and legacy-key migrations, as `showTrackGeneric` applies to a session spec's inline track keys), then writes the matching config slot. A key naming a sub-schema (`facet`, `color`) replaces the whole object, its string shorthand lifted by that schema, and `null` clears it. Keys that are not slots come back in `unapplied` as `{ key, reason }`, so a caller can tell a misspelling from a key that has an action instead of a slot. `allowSetters` also routes a non-slot key to a single-argument action named `set<Key>`. It is off by default because session specs, share links and embeds pass untyped JSON here, and a default fallback would let them call internal setters (`setError`, `setScrollTop`, ...) and call multi-argument setters with one argument. A caller that wants a specific action can call it directly. A key whose write threw is reported in `failed`. Only `failed` means the caller passed a bad value. `unapplied` needs the caller's own context to read: `showTrackGeneric` spreads the same settings into the display's snapshot, so a declared prop (`resolution`) has already landed by the time it reports here, while the restyle path spreads nothing and every entry there did nothing. A per-key error does not abort the remaining keys. A caller mid-`showTrack` has already pushed the track, and one rejected value should not leave it half-configured.	BaseDisplay
setScrollTop `(scrollTop: number) => void`		TrackHeightMixin
setHeight `(displayHeight: number) => number`		TrackHeightMixin
resizeHeight `(distance: number) => number`		TrackHeightMixin
expandToContentHeight `() => number`	Grow the track by the content it is hiding, for the resize handle's double click. Goes through `resizeHeight` so grow mode's override leaves grow first.	TrackHeightMixin
clearByteEstimate `() => void`	Drops the estimate and the viewport stamp. `forceLoadTrack` survives: it is a track-wide approval.	RegionTooLargeMixin
setForceLoadTrack `(flag: boolean) => void`		RegionTooLargeMixin
commitFetchBytes `(perRegionBytes: (number \| undefined)[], issued: GateFetchState, partial?: boolean) => void`	The byte axis of a finished fetch, called by the fetch runners with the `gateFetchState()` they captured at issue. Commits the per-region max; an empty batch, or an ungated display, commits nothing.	RegionTooLargeMixin
forceLoad `() => void`	The banner's button: exempt the track on both axes and refetch.	RegionTooLargeMixin
markCanvasDrawn `() => void`		RenderLifecycleMixin
resetCanvasDrawn `() => void`		RenderLifecycleMixin
stopRenderingBackend `() => void`		RenderLifecycleMixin
renderNow `() => void`		RenderLifecycleMixin
setRenderError `(error: unknown) => void`	set/clear the render-backend error. Called by `useRenderingBackend`: with the error when the canvas factory rejects (or context-loss re-init fails), and with `undefined` on successful (re)init and on retry.	RenderLifecycleMixin
attachRenderingBackend `<B>(backend: B, setup: () => RenderingBackendCallbacks<B>) => void`	attach a GPU/Canvas2D backend and install the upload + render autorun pair. Idempotent: re-calling swaps the backend and does not run `setup` again, so the callbacks and everything they close over are the first call's.	RenderLifecycleMixin
commitFetchResult `(commit: () => void, key: FetchKey) => void`	The commit half of a keyed fetch: run the display's own store in the same transaction as the key stamp, so no observer can see fresh data under a stale key or the reverse. As the only writer of `loadedFetchKey`, this action makes `dataCurrent` derivable, because a display cannot commit without stamping.	KeyedFetchMixin
stopActiveFetch `() => void`	Abort the in-flight fetch (if any) and retire its slot. The shared preamble of both cancel paths; the difference between them is only what they do to `fetchCanceled` / `fetchGeneration` afterward.	FetchMixin
openStatusStream `(isCurrent: () => boolean) => StatusStream`	Open one operation's slot on the display's status field: an RPC `statusCallback` throttled through the display-wide window and guarded so a callback that fires after the node is torn down (RPCs resolve their status stream asynchronously) is a safe no-op, plus the `clear` that retires the slot when the operation ends. Every operation on the display opens one, and the two come back together because an operation that never retires keeps reporting status for a phase that is over. The viewport fetch (`runFetch`), the clustering run and a lent `createAbortRotation` are three of them on one field; before ADR-081 each blanked the field outright and the last one to finish overwrote the status of the other two. `isCurrent` is required and has no "node is alive" default, because a live node is not enough: a superseded fetch is on a live node, and its late status repainting the overlay of the fetch that replaced it is the failure this guards. `runFetch` passes `!isStale()`, and every display gets that through `ctx.statusCallback` unasked; a caller outside a fetch (the clustering autorun) passes its own run's flag. Defaulting to `isAlive` made the loose answer the easy one and five displays took it. `runFetch`'s own slot is opened by the rotation; this is for an operation outside any fetch, the tree sidebar's clustering run.	FetchMixin
cancelFetch `() => void`	cancel any in-flight fetch and bump fetchGeneration (always bumps, so callers can retrigger fetch autoruns even when nothing was in flight). This is the internal reset `clearAllRpcData` runs — it clears any user-cancel flag so the retrigger actually re-fetches.	FetchMixin
cancelFetchByUser `() => void`	User-initiated cancel from the loading overlay. Stops the in-flight fetch and lands in a durable `fetchCanceled` state. Unlike `cancelFetch`, it does NOT bump fetchGeneration — so the fetch autoruns don't immediately restart the load. The user retries via `reload` (the overlay's retry button), or it clears on the next viewport change.	FetchMixin
beforeDestroy `() => void`	Abort an in-flight fetch on teardown. Without this, a display destroyed mid-fetch (track/view closed while loading) never signals the worker to abort the now-useless work, and its in-flight HTTP reads keep downloading. MST auto-chains lifecycle hooks, so a composing display can still define its own beforeDestroy.	FetchMixin
beginFetch `(signal: AbortSignal) => void`	The `onBegin` half of a fetch's bookkeeping: publish the in-flight signal (`isLoading`) and clear the durable user-cancel — a load starting is the single clear point that covers every retrigger path (reload, viewport change, settings invalidate). An action of its own for the same reason `endFetch` is: `installFetch`'s lifecycle callbacks run outside any MST flow this mixin owns.	FetchMixin
endFetch `(current: boolean) => void`	The `finally` half of `runFetch`'s bookkeeping, an action of its own because `runFetchOnce`'s `finally` resumes on a microtask the flow does not own — a direct volatile write there is outside the action context, which is the one thing hoisting the sequence into a shared function costs. The stale branch is a superseded fetch, which must not clear the loading flag the run that replaced it just set.	FetchMixin
runFetch `(work: (ctx: FetchContext) => Promise<void>) => Promise<void>`	Run a cancel-safe fetch (cancels any prior). The work callback gets a FetchContext with a signal to forward to the RPC and an isStale() check to short-circuit commits once the user has moved on. The MST-flow wrapper over the shared `runFetchOnce` sequence, and only the wrapper: the begin/clear/run/commit/error/end order, and the rules that keep a superseded run from writing back, are the same function every other fetch in the tree runs. What this adds is the observable bookkeeping a display needs — `isLoading` through `activeSignal`, `fetchGeneration`, the user-cancel clear — and the flow itself, which is an action, so `work`'s synchronous prefix runs untracked wherever a fetch autorun calls this.	FetchMixin
setShowLegend `(arg: boolean) => void`	Writes the slot, and showing the legend again restores the sections closed inside it.	LegendMixin
dismissLegendSection `(id: string) => void`	Close one section of the legend, leaving the others up.	LegendMixin
setLodTierInfo `(info: LodTierInfo \| undefined) => void`		LodTierInfoMixin

MultiWaySyntenyDisplay

Properties#

Volatiles#

Getters#

Methods#

Actions#

Properties

Volatiles

Getters

Methods

Actions