LinearMafDisplay

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

Example usage

A complete MafTrack config to paste into tracks. samples lists the aligned species in track order; rowHeight sets the per-sample band height in px (or 0 to stretch rows to fill the track height):

{
  type: 'MafTrack',
  trackId: 'multiz',
  name: 'Multiz alignment',
  assemblyNames: ['hg38'],
  adapter: {
    type: 'BigMafAdapter',
    bigBedLocation: { uri: 'https://example.com/multiz.bb' },
    samples: ['hg38', 'panTro4', 'mm10'],
  },
  displays: [
    {
      type: 'LinearMafDisplay',
      displayId: 'multiz-LinearMafDisplay',
      rowHeight: 16,
      showCoverage: true,
    },
  ],
}

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('LinearMafDisplay')`		LinearMafDisplay
configuration `configuration: ConfigurationReference(configSchema)`		LinearMafDisplay
id `id: ElementId`		BaseDisplay
layout `layout: types.stripDefault(types.frozen<S[]>(), [])`		TreeSidebarMixin
clusterTree `clusterTree: types.stripDefault(types.maybe(types.string), undefined)`		TreeSidebarMixin
clusterProvenance `clusterProvenance: types.stripDefault( types.maybe(types.frozen<ClusterProvenance>()), undefined, )`	What `clusterTree` was computed from — the locus and the settings. Set only for a tree this app computed; a supplied phylogeny (maf's `.nh`) leaves it undefined. Persisted with the tree so it survives a session snapshot, which is the case that most needs it: a shared link otherwise hands over a dendrogram with no way to learn its locus.	TreeSidebarMixin
treeAreaWidth `treeAreaWidth: types.stripDefault(types.number, 80)`		TreeSidebarMixin
subtreeFilter `subtreeFilter: types.stripDefault( types.maybe(types.array(types.string)), undefined, )`		TreeSidebarMixin
runClustering `runClustering: types.maybe(types.boolean)`	Transient declarative launch spec, the same idea as `LinearGenomeView`'s `init`: a session or config sets this true and the real clustering RPC runs once automatically, with no dialog, as soon as the display reports itself ready. `setupRunClusteringAutorun` clears it afterwards, so a saved session never re-triggers. Lives here rather than on each display because it is the trigger for a run whose output — `clusterTree`, `clusterProvenance`, `layout` — is this mixin's state. Three displays declared it identically, each with its own wrapper module that existed to code-split the clustering code and, along the way, hand-wrote the same six-member duck type of the display. Splitting inside the `run` callback does the same job and loads on a run rather than on every attach. What each run actually is stays per display, in that callback.	TreeSidebarMixin
clusterRegion `clusterRegion: types.maybe(types.string)`	Where that run reads from, as a locstring (whitespace-separated for several). Clustering is region-scoped, so running it over the visible window feeds the estimator whatever happens to be on screen; naming the locus instead lets a session cluster on the signal and then show it against its context — otherwise a zoom the user has to perform in the right order. Cleared with `runClustering`, since it is that flag's argument and a locus left standing describes a run that is not coming.	TreeSidebarMixin
sortRowsBy `sortRowsBy: types.maybe(types.frozen<RowSortSpec>())`	Transient declarative launch spec, the same idea as `runClustering`: set `{refName, pos}` to order the rows once by the value each carries at that genomic column — the session-expressible form of the right-click "Sort rows by ... here". `setupRowSortAutorun` applies it once the region containing it has loaded and then clears it, so the resulting `layout` persists but a saved session never re-sorts. Where clustering orders rows by the whole region in view and `layout` states an order outright, only this one says "rank them here", which is what lets a figure open a cohort ranked at a candidate locus with the surrounding context still on screen. What the value at the column is stays per display, in its `sortRows` callback.	TreeSidebarMixin

Volatiles

Member	Description	Defined by
wireDataMap `wireDataMap: regionDataMap<MafWireRegionData>('wireDataMap')`	Rows as the worker sent them: named by species, with no screen position. `rpcDataMap` is this placed against the current row order, and this is what a reorder re-places from instead of refetching.	LinearMafDisplay
rpcDataMap `rpcDataMap: regionDataMap<MafRegionData>('rpcDataMap')`	`wireDataMap` with every row assigned its on-screen `rowIndex` (see `placeMafRegionData`). Everything that draws, hit-tests or measures rows reads this one.	LinearMafDisplay
summaryDataMap `summaryDataMap: regionDataMap<MafSummaryRecord[]>('summaryDataMap')`	Per-region `bigMafSummary` rows for the zoom-out path, populated by `fetchMafSummaryData` only while `showSummary` is active. Kept separate from `rpcDataMap` so the GPU sequence canvas and the summary overlay never read each other's data.	LinearMafDisplay
framesDataMap `framesDataMap: regionDataMap<MafFrameRecord[]>('framesDataMap')`	Per-region CDS frame rows (UCSC `mafFrames`) for the annotation overlay, populated by the frames RPC in parallel with the main fetch. Kept separate from the alignment/summary maps so the overlay survives the summary↔detail data swap.	LinearMafDisplay
framesGateBlocked `framesGateBlocked: false`	The last frames fetch declined to read the `annotationAdapter` because its own byte estimate was over budget (`framesReadOverBudget`). The overlay is auxiliary and fails soft, so the only thing that happens is that the strip stops drawing — this is what lets the menu say so rather than leaving the tick on over nothing. Volatile and not a config slot: it describes a measurement of the current viewport, not a setting. Never in `rpcProps()` — it is written by the fetch, which is the loop trap ARCHITECTURE.md names.	LinearMafDisplay
prefersOffset `prefersOffset: true`		LinearMafDisplay
sourcesVolatile `sourcesVolatile: [] as MafSource[]`	The worker's authoritative row set, in tree (leaf) order. `layout` overlays any user reorder/relabel on top; `editableSources` merges the two and `sources` narrows that by the subtree filter.	LinearMafDisplay
treeNewickVolatile `treeNewickVolatile: undefined as string \| undefined`	The worker's guide-tree Newick (the default, before any reorder). The active displayed tree lives in the mixin's `clusterTree`, which a reorder clears (rows no longer match the dendrogram) and "Clear arrangement" restores from here — so we keep the worker tree separately rather than re-fetching it.	LinearMafDisplay
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
loadedRegions `loadedRegions: regionDataMap<LoadedRegion>('loadedRegions')`	regions whose data has been fetched and committed, keyed by displayedRegionIndex; populated only after the fetch work callback returns	MultiRegionDisplayMixin
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 string \| undefined`	The viewport key the gate last asked the adapter about, on either axis. 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
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
activeStopToken `activeStopToken: undefined as StopToken \| undefined`	stop token 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 both LGV fetch foundations compose, the same argument that put `fetchInert` below; the comparative family carries its own on `SyntenyFetchStateMixin` (ADR-054).	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 `createStopTokenRotation` 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: createStopTokenRotation(self, { statusWindow: self.statusWindow, })`	The latest-wins machine this mixin is a wrapper around, and not a second one: `createStopTokenRotation` owns token 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 token. 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). 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
hoveredTreeNode `hoveredTreeNode: undefined as HoveredTreeNode \| undefined`		TreeSidebarMixin
treeCanvas `treeCanvas: null as HTMLCanvasElement \| null`		TreeSidebarMixin
mouseoverCanvas `mouseoverCanvas: null as HTMLCanvasElement \| null`		TreeSidebarMixin
contextMenuInfo `contextMenuInfo: undefined as Info \| undefined`		ContextMenuMixin

Getters

Member	Description	Defined by
view `ModelInstanceTypeProps<_OverrideProps<_OverrideProps<…>, { ...; }>> & ... 25 more ... & IStateTreeNode<...>`		LinearMafDisplay
rowProportion `number`		LinearMafDisplay
showAllLetters `boolean`		LinearMafDisplay
mismatchRendering `boolean`		LinearMafDisplay
showAsUpperCase `boolean`		LinearMafDisplay
showCoverage `boolean`		LinearMafDisplay
showAlignments `boolean`		LinearMafDisplay
coverageHeight `number`		LinearMafDisplay
showConservation `boolean`		LinearMafDisplay
conservationHeight `number`		LinearMafDisplay
conservationMode `"base" \| "codon"`		LinearMafDisplay
rowIdentityMode `"heatmap" \| "none" \| "xyplot"`		LinearMafDisplay
rowIdentityAutoZoom `boolean`		LinearMafDisplay
showAnnotations `boolean`		LinearMafDisplay
showTranslation `boolean`		LinearMafDisplay
colorByChromosome `boolean`		LinearMafDisplay
showInversions `boolean`		LinearMafDisplay
conf `ModelInstanceTypeProps<Record<…>> & { setSubschema(slotName: string, data: Record<string, unknown>): any; setSlot(slotName: string, value: unknown): void; } & IStateTreeNode<...>`	the config typed off the concrete schema; `ConfigurationReference` erases `self.configuration` to `any`, so direct reads route through this to stay typed (same move as `BaseAdapter<CONF>`)	LinearMafDisplay
referenceSampleId `string \| undefined`	Which sample row IS the reference — the worker's own answer (`referenceSampleId`, resolved from the block whose sequence the row carries), with the view's assembly name as the fallback before any region has landed. The view's assembly name is only coincidentally the MAF's name for the reference: a MAF-tabix track sets `refAssemblyName` on the adapter precisely when the two differ, and a bigMaf/TAF file names its reference by whatever db name it was built with. Reading it here rather than in each consumer is what keeps the codon conservation band's excluded row and the per-base band's (computed in the worker) the same row. Any loaded region answers — a track has one reference species — so this takes the first that names one.	LinearMafDisplay
annotationAdapterConfig `Record<string, unknown> \| undefined`	The configured CDS-frame annotation adapter snapshot (UCSC `mafFrames`), or undefined when unset. Read from the MAF adapter config as a swappable sub-adapter (alongside `summaryAdapter`), not the display — a frozen slot, so this is a plain snapshot the frames RPC hands straight to `getAdapter`. Read with an array slot path off the live parent track, not as `readConfObject(self.adapterConfig, …)`. `adapterConfig` is itself a snapshot, and a slot read against a snapshot is the case `core/configuration/CLAUDE.md` warns about: `types.stripDefault` omits a slot sitting at its default, so the read reports a defaulted slot as absent. Harmless for these two — they default to null and are only tested for presence — but the array path costs nothing and doesn't depend on that staying true.	LinearMafDisplay
summaryAdapterConfig `Record<string, unknown> \| undefined`	The configured `bigMafSummary` sub-adapter snapshot, or undefined when unset. Same journey as `annotationAdapterConfig`. Declared here, beside its sibling, so `showSummary` has one place to ask whether the tier exists. The gate reaches the same slot through `byteGateAdapterPath` rather than through this getter, since it needs the path anyway to read the tier's own budget.	LinearMafDisplay
annotationsActive `boolean`	Whether the per-species CDS frame strip should draw: an annotation adapter is configured and the "Show CDS frames" toggle is on. The codon view consumes the same frames data but is gated separately (see `annotationDataActive`), so the strip can be off while codon view is on.	LinearMafDisplay
annotationDataActive `boolean`	Whether the frames data needs to be fetched: an annotation adapter is configured and either the strip or the codon view wants it. Gates the frames RPC and keys the fetch cache so toggling either consumer on triggers the fetch.	LinearMafDisplay
editableSources `MafSource[]`	The full row set with the user's arrangement applied: `layout` supplies order + label/color overrides, merged over the worker's `sourcesVolatile` by name. Empty `layout` (no customization) passes the worker set through. Not subtree-filtered — this is what the arrangement dialog edits. Empty until the first fetch populates the worker set; `sourcesKnown` is the readiness question. The shared `reconcileLayout`, same as multi-row features and multi-wiggle. Its append half matters here: a sample-discovery track learns of a genome only from the region whose blocks contain it (see `setSamples` / `unionSources`), and the hand-rolled merge this replaced iterated `layout` alone — so with any custom arrangement saved, a species revealed by a later region never got a row at all.	LinearMafDisplay
sources `MafSource[]`	The display rows: `editableSources` narrowed to the selected subtree. Resolved — an array, never `undefined`, the shared spelling across the row displays. The two consumers that used to read the absent case were both asking "has the species list arrived", which is `sourcesKnown`; everything else already collapsed it with `?.length` or `?? 0`. An empty array reaches here two ways that must stay indistinguishable to a renderer — no fetch yet, and a subtree filter that matched nothing — which is exactly why the readiness question needs its own name rather than a truthiness test on this.	LinearMafDisplay
sourcesKnown `boolean`	The species list has arrived from the adapter. The readiness half of what `sources` used to answer by being `undefined`: `rowsVisible` and the render callback's first-paint gate both need "a fetch has landed", and neither can get it from an empty `sources`, which a subtree filter narrowing to nothing also produces.	LinearMafDisplay
subtreeFilterSet `string[] \| undefined`	`subtreeFilter` as the worker sees it: a set, sorted, and a plain array. The one expression both the RPC payload (`fetchMafData`) and the cache key (`rpcProps`) read, so the bytes sent and the key they are cached under cannot drift apart. Sorted because the key is a JSON string while the worker consumes the value as `new Set(...)` and places rows by species name — so order is unobservable to the fetch but would still move the key. Re-picking the same clade after a re-cluster hands `setSubtreeFilter` the same names in the tree's new leaf order, which refetched every loaded region for identical data. ARCHITECTURE.md §"Row order is not a fetch input". Copied out of the MST node for the same reason: the key is a JSON string and an MST node's serialization is not this module's to depend on.	LinearMafDisplay
showSummary `boolean`	Use the cheap summary path when a `bigMafSummary` sub-adapter is configured and the view is zoomed out past the force-load threshold, which is where the detail fetch stops being affordable at all. Tracks without a summary never enter this path. `aboveForceLoadFloor` is the gate's own comparison against that threshold (`RegionTooLargeMixin`), read rather than restated so the swap and the gate can't end up disagreeing about where the floor is. It deliberately excludes the opt-in terms, which is what keeps this from being a cycle — everything below that reads this getter (`byteGateAdapterPath`) sits downstream of the floor, never upstream. The swap point is 20kb and stays there even though the byte gate has no floor at all any more: where the summary tier starts being the better picture is a rendering question, and where the detail fetch gets too expensive is a bytes question. They coincided before only because the gate had nothing to say below 20kb. `aboveForceLoadFloor` survives for this and for the density axis; nothing else compares against 20kb. Declared this early in the chain — well before the fetch and rendering getters that are its obvious neighbours — because the band layout below needs it: `coverageBandActive` is what zeroes the band's height, and `rowsTopOffset` (and the whole height cascade under it) is resolved long before here. Both its inputs come off the compose, so there is nothing to order it after.	LinearMafDisplay
coverageBandActive `boolean`	The coverage band is on and has data to put in it. `showCoverage` is the user's setting — the menu ticks it, a config sets it — but the band's depths come from `coverage.coverageDepths` on the alignment blocks, and the summary path clears `rpcDataMap` on purpose. Reading the setting as if it answered both questions left the band reserving `coverageHeight` px above the rows and painting nothing whatsoever into them: no bars, no axis, no label — ~45px of dead chrome on every track with a `summaryAdapter` zoomed out past the floor. Everything that lays the band out, paints it, hit-tests it or exports it reads this; only the track menu reads `showCoverage`, so the tick keeps reporting what the user chose rather than where they happen to be zoomed — and zooming back in restores the band without touching the config. Same split as `basesRenderingActive` vs `activeRowRendering`, for the same reason.	LinearMafDisplay
conservationBandActive `boolean`	The conservation band is on and has data to put in it — the exact twin of `coverageBandActive`, and it exists because the band had the bug that getter was written to fix. Percent identity is computed from the alignment: the per-base mode reads `coverage.identityScores` off the blocks and the codon mode translates them, so both come out of `rpcDataMap`, which the summary path clears. `showConservation` alone therefore left 40px of band, a fixed 0–100% axis and a resize handle drawn over nothing at every zoom past the floor. Unlike coverage it is off by default, which is the only reason it went unnoticed for longer. Same split as its twin: everything that lays the band out, paints it or exports it reads this, so the menu tick keeps reporting what the user chose and zooming back in restores the band without touching the config. The one other reader of the raw setting is `annotationDataActive`, and it has to stay raw: it is an `rpcProps()` cache key, so resolving it through this getter would make the key zoom-dependent and drop every loaded region on each crossing of the summary floor. Fetching frames the codon band can't draw yet costs one small read; refetching the alignment costs the tier swap twice over.	LinearMafDisplay
samples `Sample[]`	Sample list keyed by sample id (alias of `sources` mapped to the project's canonical `{ id, label, color }` shape). Consumed by MafSequenceWidget, color legend, etc.	LinearMafDisplay
rowIndexBySrc `Map<string, number>`	Maps a `src` (species) to its display row index. The single source for the `src`→row projection used by the summary-bar and CDS-frame overlays and the frame hover lookup, so they can't disagree on row placement.	LinearMafDisplay
defaultCodonSpecies `string \| undefined`	The anchor species whose `mafFrames` reading frame is used to translate every row (UCSC `codonDefault`). Tied to the reference assembly, not the top display row: every species' codon is compared against the reference sequence (`block.refSeqBytes`), so the frame must be enumerated from the reference's own frames. A row reorder (layout) can move a non-reference species to row 0 — reading `sources[0]` there would enumerate codons in the wrong frame. Falls back to the worker's canonical first row (pre-reorder) when the reference isn't itself a listed sample. The reference is `referenceSampleId` — the row the worker saw carrying the reference sequence — not the view's assembly name, which is a different string whenever the MAF names its reference differently.	LinearMafDisplay
coverageDisplayHeight `number`	Height of the coverage band above the rows (0 when hidden, and on the summary path, where it has nothing to draw).	LinearMafDisplay
conservationDisplayHeight `number`	Height of the conservation (percent identity) band (0 when hidden, and on the summary path, where it has nothing to draw).	LinearMafDisplay
rowsTopOffset `number`	Top offset of the per-sample rows area = the stacked band heights above it (coverage + conservation). The single source of truth for "where the rows start" — every rows hit-test / draw / export offset routes through this so adding a band can't desync them.	LinearMafDisplay
nrow `number`	Number of displayed rows (at least 1, so the fit-mode division is safe).	LinearMafDisplay
rowsVisible `boolean`	The per-sample rows area has something to draw: the view can place it, the rows are shown at all, and the row set is known. Every rows layer is a full per-cell scan of the visible blocks, and with `showAlignments` off the area is 0px tall — so the gate lives here rather than being re-spelled by each `visible*` getter, which is how the summary bars came to be the only rows layer that could run before the view was initialized.	LinearMafDisplay
maxRowsHeight `number`	Max CSS-px height the rows canvas may take before its backing store (`× dpr`) hits the browser/GPU canvas limit. The single ceiling both the fit-target sizing and the `rowHeight` cap respect.	LinearMafDisplay
fitTargetHeight `number`	The track height that fit-to-height mode divides among rows. Once the user drags, the explicit `height` config slot wins; before any drag we size to show every row at the default px height, so a typical alignment looks exactly like fixed mode. Bounded by `DEFAULTS.maxAutoFitHeight`, past which the rows shrink instead of the track growing. Sizing purely to content made the default height scale with the species count — 4141px for a 447-way, across a stack of full-height overlay canvases — and left `maxRowsHeight` (a crash guard, at the backing-store limit) as the only thing bounding it. This is the policy bound; that one stays as the hard floor under a deliberate drag.	LinearMafDisplay
rowsHeight `number`	Height of the per-sample rows viewport — the track height minus the stacked bands, which is exactly the rows canvas. Zero when alignments are hidden, collapsing the display to the coverage band. This is the viewport, not the content: with a fixed `rowHeight` the rows can add up to far more than this and the extra is reached by scrolling (`rowsContentHeight` / `scrollableHeight`), never by growing the canvas. Capped at `maxRowsHeight` so even a deliberate drag can't push the backing store past the browser/GPU canvas limit.	LinearMafDisplay
resizableBandBounds `{ max: number; }`	The legal range for the two drag-resizable bands stacked over the rows (coverage, conservation). The ceiling is what makes the drag recoverable: `rowsHeight` above floors at 0, so without one a band dragged past the track height squashes the rows to nothing and carries its own resize handle — drawn at the band's bottom edge — off the display, leaving no way back. Bounded against `fitTargetHeight`, the same pot `rowsHeight` divides, and per band rather than across both: two bands dragged large can still crowd the rows, but each stays reachable.	LinearMafDisplay
autoRowHeight `number`	Per-row height in fit-to-height mode: the rows viewport split evenly across rows, so the content always fits exactly and the display never scrolls in this mode. Deliberately NOT floored at 1px. A sub-pixel row is the legitimate answer for more species than the track has pixels, and flooring it made the rows area taller than the height it was asked to fit inside — which defeated `fitTargetHeight`'s own ceiling past ~555 species (2000 species floored to 1px re-grew the track to 2045px) and would now make fit mode report a phantom scroll. The non-positive guard belongs in `effectiveRowHeight`, which is the resolved value consumers divide by. Same rule, and same regression, as the multi-sample variant display's `autoRowHeight`. A fixed height goes the other way and is used as-is however many species there are: the rows canvas is the viewport (`rowsHeight`), so hundreds of tall rows cost scroll extent, not backing store. The canvas-size ceiling that `effectiveRowHeight` used to apply — shrinking every row so the whole stack could be one canvas — now lives on `rowsHeight` itself, where the canvas actually is.	LinearMafDisplay
rowsContentHeight `number`	Height the per-sample rows add up to — the scrolled content behind the `rowsHeight` viewport. Equal to it in fit-to-height mode (which is what makes that mode never scroll); larger whenever a fixed `rowHeight` asks for more rows than the track shows.	LinearMafDisplay
totalHeight `number`	Full display height = rows viewport + stacked bands.	LinearMafDisplay
scrollableHeight `number`	Max valid `scrollTop`: how far the rows scroll before the last one reaches the viewport floor. Zero when they fit, so this doubles as the "does this display scroll" answer (the scrollbar and the wheel handler both read it). Fit-to-height always fits.	LinearMafDisplay
height `number`	Override BaseLinearDisplay.height so the track container matches the rendering canvases exactly (stacked bands + rows viewport).	LinearMafDisplay
hierarchy `ClusterHierarchyNode \| undefined`	Positioned tree hierarchy. Coordinates are computed against `(rowsContentHeight, treeAreaWidth)` so leaf rows align with row tops even where the rows scroll past the viewport — the tree canvas and the SVG labels shift the whole thing by `scrollTop`, exactly as the rows do. The coverage band is offset separately by the React layer.	LinearMafDisplay
spatialIndex `TreeSpatialIndex \| undefined`		LinearMafDisplay
colorPalette `MafColorPalette`	Theme-derived color palette (per-base colors + match/gap/mismatch/ unknown/insertion), read by `gpuProps()` and `renderState`. Derived from the session theme so it's always available — including headless SVG export and RPC, where no component mounts to seed it. Theme changes trigger a main-thread re-encode but never an RPC refetch.	LinearMafDisplay
encodeBinBp `number`	Genomic bp the GPU encoder collapses into one cell — `subPixelBinBp` off the debounced `coarseBpPerPx` (the same input `zoomedToBaseLevel` uses), which the encode autorun tracks. Zoomed in this is `1` (encode every base). Once a base falls below half a CSS pixel the per-base quads are individually invisible — a 500kb region across 10 species emits 1.7M of them into a 28MB buffer, all but ~15k of which lose the sub-pixel race for their pixel — so the encoder decimates to one sample per bin instead.	LinearMafDisplay
coverageDomain `[number, number] \| undefined`	[min, max] coverage domain over the currently visible content blocks, derived from the worker-shipped `coverage.coverageDepths` arrays (which already reflect the active subtree — see `rpcProps`). Linear and unbounded: sample counts are already bounded and well-distributed, so this display composes no score axis to configure. Feeds `coverageTicks`.	LinearMafDisplay
coverageTicks `YScaleTicks \| undefined`	Y-axis tick marks for the coverage band.	LinearMafDisplay
coverageBandColors `{ colors: MafCoverageColors; gpuColors: CoverageBandColors; }`	The coverage band's colours, in both representations the two backends need: CSS strings for the Canvas2D painters, packed ABGR for the GPU passes. Its own getter so the pack — which parses nine CSS colours — is memoized against the palette rather than re-run inside `renderState`, which every scroll frame invalidates.	LinearMafDisplay
coverageBandState `MafCoverageBandState \| undefined`	The coverage band as the renderers take it, or undefined for "draw no band": the setting is off, the summary tier owns the view, or the autoscaled domain has not resolved yet. Every mark in the band is a fraction of the domain max, so the third case is not a shorter band — it is bars of arbitrary height, which is why one nullable object carries the height and the domain together.	LinearMafDisplay
renderState `MafGPURenderState`	Render state passed to GPU/Canvas2D backend each frame. `canvasHeight` is the WHOLE canvas — the stacked bands plus the rows viewport — because the coverage band draws on the same canvas as the rows, scissored out of it, the way the alignments display draws its coverage band above its pileup. A display gets one rendering backend, so a second GPU band cannot mean a second canvas. `rowsTop` / `rowsHeight` are the rows band inside it.	LinearMafDisplay
inversionConsensus `StrandConsensus`	The orientation each (row, source chromosome) is measured against for the inversion indicator (`consensusStrandByRowChr`). A memoized computed for the same reason as `sourceChromRanks`: it walks every block × row of every loaded region — deliberately, so the consensus stays put as the user scrolls within loaded data — while its only consumer runs on every pan and zoom. Empty when the indicator is off, so a track that never shows inversions pays nothing.	LinearMafDisplay
visibleEmptyLines `EmptyLineSegment[]`	Positioned bridge-line segments for `e`-line (empty/bridged) rows.	LinearMafDisplay
visibleDeletions `DeletionMarker[]`	Positioned deletion runs for the visible aligned rows; the overlay draws the deleted-base count inside each run when it fits.	LinearMafDisplay
visibleInversions `InversionMarker[]`	Positioned strand-flip (inversion) markers for the visible aligned rows. Empty unless the indicator is toggled on.	LinearMafDisplay
zoomedToBaseLevel `boolean`	At base level each reference base spans at least a pixel, so individual bases / SNP marks are legible (UCSC's `zoomedToBaseLevel`). Read off the debounced `coarseBpPerPx` so the rendering swap it gates doesn't thrash mid-zoom. False until the view is initialized.	LinearMafDisplay
selectedRowRendering `RowRendering`	The row coloring the user picked, as one value across the three slots that store it. `activeRowRendering` below is what is actually painting; this is the setting behind it, and the two differ wherever zoom or the summary path overrides the choice. Zoom-independent on purpose. The radio it drives would otherwise move its own tick as the user zoomed — the identity plot yields to the bases at base level, codon view only exists there — which reads as the menu changing the setting behind their back. This is where precedence between the three slots is decided, once: `activeRowRendering` starts from the answer rather than re-deriving it, so the two cannot disagree about which setting won.	LinearMafDisplay
activeRowRendering `"bases" \| "codon" \| "sourceChrom" \| RowIdentityMode`	Single source of truth for what the per-sample rows area draws right now: `bases` (the GPU SNP/base coloring), `codon` (per-codon change coloring from `mafFrames`), `sourceChrom` (color-by-source-chromosome SV mode), or a per-row identity style (`heatmap` / `xyplot`). The GPU canvas, the identity/chromosome canvases, the codon overlay, and SVG export all branch on this one getter so they can't disagree about what's on screen. `selectedRowRendering` is the setting; this applies the two things that can override it, and falls back to the bases — the rendering that needs nothing beyond the alignment — whenever it does: - the cheap summary path carries neither per-row bases nor per-row source chromosomes, so no alternative can draw from it; - zoom, in the two directions UCSC `wigMaf` uses. Codons only exist at base level, and with `rowIdentityAutoZoom` (the default) the identity plot yields to the bases there, where the letters say more than a per-pixel mean of them. Auto off pins the plot on at every zoom. Deriving from the selection rather than restating its precedence is also what keeps a config that sets two of the three slots — the state the old menu of independent checkboxes could reach, and a hand-written config still can — painting the one the menu ticks. Re-deriving let a lower-precedence slot take over at the zooms where the winner couldn't draw, so the menu said "Codon changes" while the rows were colored by source chromosome.	LinearMafDisplay
basesRenderingActive `boolean`	The GPU base canvas owns the rows: per-base SNP cells are what's painted, so the per-base letters draw, insertion markers are live (drawn, hoverable, clickable), and the encode autorun has a buffer worth building. Named once here because it is the question six consumers ask — the encode and render callbacks, the insertion overlay and its cursor, the insertion click, and SVG export — and a mode added to `activeRowRendering` has to reach all six or the markers keep drawing over a rendering that isn't theirs. Not simply `activeRowRendering === 'bases'`. That getter answers which of the selectable renderings wins, and summary mode resolves to `bases` there because none of the alternatives can draw from summary rows. But the base canvas can't draw from them either: `fetchMafSummaryData` clears `rpcDataMap` on purpose, and the rows the user sees are the summary overlay's. So the two questions genuinely differ here, and answering this one with that one pinned the display in `loading` forever — the render callback took the paint-from- `rpcDataMap` branch, `renderBlocks` returned `painted: false` over an empty map every frame, and `canvasDrawn` never flipped, so `computeLoadingTerm`'s `rendersCanvas && !canvasDrawn` stayed true under a track that was fully loaded and visibly drawn.	LinearMafDisplay
rowsCanvas2dMode `"sourceChrom" \| RowIdentityMode \| undefined`	Which rendering the sibling Canvas2D rows layer paints, or undefined when it paints nothing (`bases` is the GPU canvas, `codon` is its own overlay). The on-screen canvas and SVG export both branch on this rather than re-deriving the same cascade, which is what let the export grow a four-branch chain against the canvas's two.	LinearMafDisplay
visibleLabels `VisibleLabel[]`	Positioned per-base SNP/sequence letters. Suppressed in any non-base rendering (the identity plot and codon view both replace the letters).	LinearMafDisplay
visibleInsertions `InsertionMarker[]`	Positioned insertion markers (interbase) for the visible aligned rows. Lives here, past `basesRenderingActive`, rather than beside the other block overlays: the markers are drawn only in `bases` mode (the overlay and the SVG export both gate on it), so the identity plot, codon view and color-by-chromosome were each paying a full per-column insertion walk of every visible block × row, every frame, for markers nothing rendered. The identity plot is the expensive case — it is the zoom-out default once `rowIdentityMode` is set, which is exactly where the walk covers the most blocks. Same mistake, and same fix, as the deletion overlay building 679k markers to draw none; see agent-docs/reference/MAF_LARGE_BLOCKS.md. The hover hit-test does NOT read this — it resolves insertions from the blocks directly (`findRowHoverAtBp`) — so gating costs no interactivity.	LinearMafDisplay
visibleSummaryBars `SummaryBar[]`	Positioned per-species presence bars for the zoom-out summary overlay. Unmatched `src` rows drop via the `sources` index, keeping the render robust to summary files that list extra species. Drawn on the summary tier, and as the coarse stand-in for a region the detail tier hasn't landed yet — which is the swap back in, and used to be a blank track. Zooming in past the floor stays spatially inside the region the summary fetch loaded, so `viewportWithinLoadedData` is true and `canvasDrawn` is already set: the display reads as `ready` with nothing in it, for the 600ms fetch debounce plus the alignment RPC, which on a deep alignment is the slow one. Nothing was wrong except that the rows we could still draw had been switched off. Suppressed per region rather than in one decision, because the tiers arrive per region: the one under the cursor can be showing bases while its neighbour is still bars. `showSummary` short-circuits it because the two maps can both hold a region — zooming back out reuses the summary cache and never calls `clearAlignmentData`, and the bars are what is on screen there.	LinearMafDisplay
visibleFrames `FrameMarker[]`	Positioned per-species CDS frame boxes for the annotation overlay. Empty unless an annotation adapter is configured and the overlay is on. Reuses the `src`→row mapping the summary bars established, so frame rows for species the track doesn't list drop out.	LinearMafDisplay
codonCellsActive `boolean`	The codon overlay is what the rows area is painting.	LinearMafDisplay
codonConservationActive `boolean`	The conservation band is in per-codon (amino-acid identity) mode, with frames to define codons and per-base blocks to translate — the cheap summary path ships neither.	LinearMafDisplay
locatedCodons `LocatedCodon[]`	Every reference codon the fetched blocks resolve, in the anchor species' reading frame — the shared spine of the codon cells and the codon conservation band. A memoized computed rather than a call inside each consumer: the resolution (enumerate the anchor's codons, index every block's reference columns, locate each codon) is the expensive half, and with both modes on it used to run twice per frame. Empty when neither consumer is active, so a track with codon view off pays nothing.	LinearMafDisplay
sourceChromRanks `{ ranks: Map<number, Map<string, number>>; maxRank: number; }`	Each row's source chromosomes ranked by aligned bp (`perRowChromRanks`). A memoized computed for the same reason as `locatedCodons` above: the rank walk covers every block × row of every loaded region, and it had two independent callers — the legend (already a cached computed) and `drawSourceChrom`, which recomputed it inside a draw that re-fires on every pan and zoom. Ranked over the loaded regions, exactly as `inversionConsensus` is, and for both of its reasons. The colors stay put as the user scrolls within loaded data — a rank is a claim about the row, and a block ought not change color because a pan brought a different scaffold into view — and the walk re-runs on new data rather than on movement. It used to be keyed on `renderBlocks`, which is rebuilt on every pan tick (its `screenStartPx` moves), so the memo missed on every frame of a pan and re-ranked every (block, row) pair to produce the identical map: those blocks only selected which region to walk, and the region they selected carries the whole buffered span either way. Pinned by `sourceChromRanks.test.ts`. Empty when the mode is off, so a track that never colors by chromosome pays nothing.	LinearMafDisplay
visibleCodons `CodonMarker[]`	Per-species codon cells for the codon view (the per-codon change coloring that replaces the SNP cells). Empty unless codon view is the active rendering and an anchor species is known.	LinearMafDisplay
visibleCodonConservation `CodonConservationBar[]`	Per-codon amino-acid conservation bars for the conservation band's codon mode. Draws only inside the CDS (where frames define codons); everywhere else the band is blank.	LinearMafDisplay
bandLabels `{ text: string; top: number; }[]`	Titles for the stacked bands, with the y they sit at — empty unless both bands draw, which is the only case they are needed for: two stacked filled-histogram bands are otherwise told apart only by their Y-axis units (depth vs %). A getter for the same reason as `legendItems` below: the on-screen labels and the SVG export both read it. The export had no titles at all, so the one figure that needs them most — both bands drawn, and an exported PNG where nothing can be hovered to disambiguate — was the one shipping without them. The conservation title names what the band is drawing (`codonConservationActive`), not the mode that was asked for: codon mode falls back to per-base wherever frames or per-base blocks are missing, and a band captioned "aa identity" while drawing nucleotide identity is worse than no caption.	LinearMafDisplay
legendItems `LegendItem[]`	The color key for whatever `activeRowRendering` is painting, or empty where the rendering needs no key (plain bases). One getter rather than a component per mode, because both the on-screen legend and the SVG export read it — an exported codon or source-chromosome figure whose swatches are its only decoder used to ship with no key at all. A dispatch, not a description: each key is built by the module that paints the rendering, out of the colors it paints with. Written out here instead, all three had drifted from the screen — the codon swatches skipped the alpha the cells are composited with, the X-Y plot got the heatmap's ramp when it paints one color and varies height, and the source-chromosome key kept adding rows past the point where its palette stops changing.	LinearMafDisplay
msaHighlights `MsaHighlight[]`	Get highlight regions from connected MSA views	LinearMafDisplay
gateEnabled `boolean`	Enable byte-estimate gating: a MAF-aware byte estimate (per-species sequence × span) is checked against `fetchSizeLimit` inside the tier's own RPC, blocking the fetch with a force-load prompt rather than downloading hundreds of species' bases at genome scale. On for both tiers, and `byteGateAdapterPath` below is what makes that safe: each RPC measures the file it actually reads — the alignment index on the detail path, the `summaryAdapter` sub-adapter on the summary one. This used to be `!showSummary`, exempting the summary tier on the grounds that it is the cheap one. It is cheap per base — no sequence — but it is still a whole-feature download (`BigBedAdapter.getFeatures`), and `showSummary` covers every zoom from 20kb to the whole genome. So the one path that existed to escape the gate was also the one that could pull an unbounded number of per-species records with nothing quoting the size. A genuinely small summary read is nowhere near `fetchSizeLimit` and never sees a banner; that is the estimate's job to decide, not this getter's.	LinearMafDisplay
byteGateAdapterPath `string[]`	Measure whichever tier is about to be fetched: the `summaryAdapter` sub-adapter while `showSummary`, otherwise the MAF adapter itself. Without this the summary tier would be gated against the alignment's estimate — a number describing a download that isn't happening, which at genome scale would block the cheap tier on the expensive one's cost. The only hook the swap needs: `byteGateAdapterConfig` is the config at this path and `adapterFetchSizeLimit` is that config's own `fetchSizeLimit` slot, so the measurement and the budget describe one file by construction rather than by two overrides agreeing. Reading `showSummary` here is not a cycle: it resolves through `aboveForceLoadFloor`, which deliberately excludes every opt-in term (`RegionTooLargeMixin`), so nothing in the gate is upstream of it.	LinearMafDisplay
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
hoveredFeature `unknown`	Overridable hook (default `undefined`): what the pointer is currently over, for readers outside the display. `LinearGenomeViewContainer` publishes it to `session.hovered`, the view-wide "what is the user pointing at" channel a plugin can subscribe to. Declared here because a cross-display consumer can only read a name the base declares — the same reason `SyntenyFetchStateMixin.fetchInert` is a hook rather than a getter each display invents. The container used to read `featureUnderMouse`, which only the wiggle, alignments and Manhattan families spelled that way — canvas said `hoveredFeature`, variants `hoveredGenotype` — so the channel carried a hover from a third of the display types and nothing said which. It also asked only `displays[0]` of each track. `unknown` because the payload genuinely differs — a read, a wiggle bin, a SNP, a genotype cell — and `session.hovered` is typed to match ("can be anything; code that wants to deal with this should examine it"). Narrow it in the override.	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; }`	Overridable hook: which widget `openFeatureWidget` opens for one of this display's features. The default is the generic one, which is what a display drawing plain features wants and what the canvas base spelled out by hand. An override is a display whose features have a vocabulary of their own — a read, a variant, a synteny block — and the `id` is deliberately part of it: two displays naming one id share the drawer panel, which is the behaviour when the two are showing the same kind of thing.	BaseDisplay
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. Reading it here is what makes `self.resizing` available to a display that did.	TrackHeightMixin
host `RegionHost`	The containing LinearGenomeView, typed once for every display in this family — see `containingHost` for the cast it owns and why both foundations still declare the name.	MultiRegionDisplayMixin
canvasWidthPx `number`	The CSS width of this display's on-screen canvas, in px — and the `canvasWidth` its `renderState` must carry, since the two have to agree or the bp→px mapping is scaled against a box it doesn't fill. `trackWidthPx`, not `view.width`: `TrackRenderingContainer` insets the rendering component by the 2px track outline under `contain: strict`, so a `view.width`-wide canvas overhangs its own container and the browser clips the overhang away. It renders almost identically, which is why MAF drifted onto `view.width` uncaught. A getter rather than a note on each display, because the choice was being made by copying a neighbour out of four plausible view getters — `width` (the viewport), this one, and `totalWidthPx` / `totalWidthPxWithoutBorders` (the content width, which the global family's heatmaps legitimately want: a different question, not a different answer). `no-restricted-syntax` bans the underlying read everywhere but this line, since a second spelling agrees until it doesn't. SVG export is the one exception: the export shell has no outline, so `renderSvg` overrides `canvasWidth` with the shell's own width (see `LgvSvgBodyProps`).	MultiRegionDisplayMixin
canRender `boolean`	Overrides `RenderLifecycleMixin`'s default-true hook with the LGV precondition both foundations share — see `foundationCanRender`.	MultiRegionDisplayMixin
viewportWithinLoadedData `boolean`	true when every visible block lies within an already-fetched region — i.e. the viewport shows data we actually loaded, not the stale fringe left after a zoom-out/pan. Drives the loading overlay through the pre-refetch debounce. Spatial only, and it stays that way. Whether the data held for a block is still what a fetch would bring back is `isCacheValid`, which `dataCurrent` conjoins for the export gate. The scrim reads this getter alone: a phase that went `loading` on a moved `regionFetchKey` would raise the overlay into every zoom.	MultiRegionDisplayMixin
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`.	MultiRegionDisplayMixin
layoutReady `boolean`	Overridable hook (default false): whether a searchable feature layout currently exists. Any display defining a feature-lookup method (`searchFeatureByID`, `getFeatureById`) must override it, so callers can tell "laid out, but off-display" from "no layout exists yet" — a distinction only the display can make. See packages/display-kit/CLAUDE.md §"Four readiness axes".	MultiRegionDisplayMixin
regionFetchKey `string`	Overridable hook (default `''`): what a fetch issued right now would produce for a region, as a string — the display's per-region content axis. `fetchRegions` captures it before it issues the RPC and stamps it beside the loaded region; `isCacheValid` refetches a region whose stamp no longer matches. Wiggle returns `String(view.bpPerPx)` (adr-008), canvas the peptide-overlay threshold, the variant matrix its zoom in matrix mode only. NOT an `rpcProps()` field: this invalidates one region's held data where `rpcProps` invalidates all of it, and a zoom-swinging value in the RPC payload blanks the display at the force-load floor — see REGION_TOO_LARGE.md §"How the verdict is built". A getter, so the observables it reads register as dependencies of `FetchVisibleRegions`; MobX runs an action untracked and the autorun would keep a stale answer.	MultiRegionDisplayMixin
dataSuperseded `boolean`	Overridable hook (default false): the held data is loaded and covers the viewport, but a fetch input has moved past it, so the data is about to be cleared and refetched. A display says so here rather than overriding `dataCurrent`, for the reason `FetchMixin.fetchInert` is a hook: an override has to restate the freshness terms and then misses the next one added. On screen this window is invisible (the clear lands a tick later and the loading scrim covers it), which is exactly why it needs saying: `awaitSvgReady` samples freshness once, and an export that samples it inside this window renders the data that is about to be discarded — or, once the clear lands mid-render, nothing at all. GWAS's LD auto-index is the case: adopting the top hit as the index SNP is an `rpcProps` change, so the very load that produced the top hit is what it invalidates. The input need not have settled yet. Alignments counts the debounce window ahead of its per-base bin, where the bin the data was fetched under has not moved and the clear is inevitable rather than committed. That is the half of the window an export lands in, since a reader zooms and then reaches for the menu. What may NOT go in is a change that could still be taken back: this fails hung, not stale. So state the live-vs-settled half as a value compare and leave key strings alone. The settled half — the stamp a fetch committed under against the key a fetch now would use — is the foundation's already, through the `isCacheValid` term in `dataCurrent`, and an override restating it buys nothing: a second derivation of the key's vocabulary reads `"16\|fine"` against a live `"16"` the day the key grows an axis, latches this true, and every export of the display then waits out `awaitSvgReady`'s backstop instead of failing.	MultiRegionDisplayMixin
renderBlocks `RenderBlock[]`	Shared cached view for every LGV-based GPU display. A single displayedRegion may produce multiple render blocks (shared GPU buffer, different scissor clips on screen). Plugins that want to suppress rendering in certain states (e.g. no domain yet) can override this getter to return [] — the autorun lifecycle will then issue an empty-blocks render that clears the canvas.	MultiRegionDisplayMixin
dataCurrent `boolean`	This family's answer to the shared freshness question every display foundation must answer (`dataCurrent`): the held data corresponds to what is on screen right now. Four terms — spatial coverage of every visible block, `loadedRegions.size` to rule out the vacuously-true empty viewport, `isCacheValid` per block, and the display's own `dataSuperseded`. Regions stream in one at a time, so this (not "the first datum arrived") is what keeps a multi-region/whole-genome export complete. `isCacheValid` belongs here and not in the scrim. Coverage answers "is the data here", never "is it what a fetch now would bring back", so a zoom that moves `regionFetchKey` leaves every held region covered and stale at once — and an export sampling `svgReady` across that window painted bins the worker computed for the previous zoom. `displayPhase` still reads `viewportWithinLoadedData` alone: folding staleness into the phase raises the loading scrim into every zoom, which is the trade REJECTED_IDEAS.md "Folding content staleness into `displayPhase`" turned down and this does not take. The term cannot latch, and the reason is structural rather than a case list: a block reaches `fetchNeeded` unless `planRegionFetch` finds it ungated, covered AND cache-valid, and it reads that last term tracked. The `&&` short-circuits ahead of it drop its observables only where the block is fetched anyway, so the key move that closes this gate is the same read, in the same dependency set, that wakes the refetch reopening it.	MultiRegionDisplayMixin
loadedAssembly `(ModelInstanceTypeProps<…> & { error: unknown; loadingP: Promise<…> \| undefined; ... 10 more ...; refNameMismatches: Map<…>; } & ... 13 more ... & IStateTreeNode<...>) \| undefined`	The assembly the data in hand came from, once it can answer about refNames — `undefined` before that. Off the first LOADED region rather than the view's displayed ones, which is the distinction that makes it belong here: a display holding fetched data is asking about the assembly THAT data is on, and the view's regions can already have moved on. The `initialized` gate is why this returns the assembly rather than its name. `getCanonicalRefName2` and `refNameToIndex` answer WRONGLY rather than throwing before the aliases land — identity, and a miss — so a caller that skips the gate gets a plausible answer and no signal. Handing back `undefined` until it can answer is what makes the caller write its fallback.	MultiRegionDisplayMixin
svgReady `boolean`	true once an off-screen (SVG) export can safely read this display's data. Policy single-sourced in `computeSvgReady`; this family supplies only the freshness half, which `foundationSvgReady` reads as `dataCurrent` or the vacuous currency of `viewportEmpty`. Off-screen renderers gate on it via `awaitSvgReady(model)` instead of inlining the condition.	MultiRegionDisplayMixin
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.	MultiRegionDisplayMixin
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 `computeLoadingTerm` reaches all three without being wired three times. This family's argument is spatial: `loading` also covers stale data (viewport past loaded) still on screen through the pre-refetch debounce. A thunk, so a suppressed or already-loading display doesn't subscribe to viewport churn. A subclass customizes this through `fetchInert` (FetchMixin), never by overriding the getter — see that hook.	MultiRegionDisplayMixin
densityGateEnabled `boolean`	Whether the density axis applies. `CanvasFeatureGateMixin` contributes `true` beside its measurement; byte-only displays leave it.	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`	The display's `fetchSizeLimit` slot, from `regionTooLargeConfigSchemaFields`.	RegionTooLargeMixin
densityTooLarge `boolean`	The density axis's verdict; canvas overrides 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. 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.	RegionTooLargeMixin
byteGateAdapterKey `string`	Which tier the estimate is about, as a comparable string.	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 is about a viewport the user has since left. True before any measurement.	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`	`gateActive` plus the density axis's own terms: the axis is on, and the span is above the floor.	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
rendersCanvas `boolean`	Overridable hook (default true): whether this display paints a canvas in its current configuration, as opposed to a deliberate static placeholder (LD with the triangle off, sequence past base resolution — both render a message where the `<canvas>` would go, so `canvasRef` is never called and `canvasDrawn` can never flip). Lives here, beside `canvasDrawn`, because every consumer of "has this display painted" needs the pair — and until 2026-08 each family declared its own copy (per-region hard-coded `true`, global carried the hook for LD), so a display could express the state only to whichever family it happened to compose. See `painted` below for the reader that was missed.	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 saying otherwise is a lie that never resolves. 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 burn its full timeout — silently, since that wait swallows its own. Same shape as `fetchInert` on the comparative side: the reader you forget 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. See that hook.	RenderLifecycleMixin
isLoading `boolean`	true while a fetch is active	FetchMixin
isLoadingOrCanceled `boolean`	`isLoading` widened to cover a user-canceled load. This, not `isLoading`, is what a `displayPhase` loading term wants. `cancelFetchByUser` clears the stop token synchronously, so `isLoading` goes false the instant the user clicks Cancel — and the loading overlay that unmounts on it is carrying the Retry button, which is the only way back: the state is deliberately durable, so no autorun restarts the fetch on its own. A bare `isLoading` therefore reads as `ready` over a display that is stopped, empty and offering nothing. Arc read `isLoading` directly and had exactly that hole. It is a getter here so no family has to remember the second term.	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, three readers, and that is the whole point — a display that grows such a state has one thing to say rather than three, and the reader it would have forgotten is always the one outside itself: - the loading scrim (`computeLoadingTerm`), which otherwise parks over the placeholder, permanently once a cancel has been clicked; - the SVG export (`computeSvgReady`'s `extraTerminal`), whose `awaitSvgReady` is an unbounded `when`, so one such display hangs the whole view's export; - the dev-only retry check (`makeRetryContractCheck`), which would otherwise report a dead Retry on a display correctly declining to load anything. It was 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 one of the three was hard-coded `false` on the global family for a while, which is how LD came to be able to express only half its own state. Same name and same meaning as `SyntenyFetchStateMixin.fetchInert` now, so the retry check reads one field across all three fetch families. ADR-082. A hook rather than a `displayPhase` override, because overriding the getter means restating the whole loading condition — which is how sequence came to hold a verbatim copy of the other terms, one `git blame` away from silently missing the next one added. It 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 dev-only retry 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 say it, one per fetch foundation, which is why 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, so no run is ever judged and the display has silently opted out — an exemption by another name. HiC is in that shape 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
rpcPropsCacheKey `string`	The RPC cache key both fetch foundations invalidate on: this display's `rpcProps()` payload serialized to a string. `serializeRpcProps` owns the why, including the silently-dead-axis corollary. Here, beside the two hooks above, for the same reason they are: it describes the display, and every foundation composes this mixin. The per-region family watches it from `SettingsInvalidate` and the global one from its fetch autorun's trigger list — one getter and one name, so the two cannot come to invalidate on different axes. The global side built its own local `computed` over the same function until 2026-08, which was the same value under a second spelling.	FetchMixin
rowHeight `number`	Raw per-row height setting: `0` is fit-to-display-height, any positive value is a fixed px height. The resolved value is `effectiveRowHeight` — consumers read that, never this. On the config rather than the display snapshot for the same reason `height` is: the config node outlives the display instance, so a fixed height survives unticking and reticking the track.	RowHeightMixin
effectiveRowHeight `number`	Resolved per-row height. `rowHeight === 0` divides the display's own `autoRowHeight` across the rows; any positive value is the fixed px height, used as-is however many rows there are. Sub-pixel is legitimate and deliberately not floored here — a cohort with more rows than the track has pixels has a genuinely fractional row height, and flooring it makes the content taller than the height it was asked to fit inside. `resolveRowHeight` floors only a non-positive result, which consumers divide by.	RowHeightMixin
showTree `boolean`	Whether the dendrogram sidebar is drawn.	TreeSidebarMixin
showBranchLength `boolean`	Whether tree nodes are positioned by branch length (dendrogram) or evenly by topology (cladogram).	TreeSidebarMixin
showRowLabels `boolean`	Whether each row's name is drawn over the left of the plot.	TreeSidebarMixin
parsedTree `HierarchyNode<NewickNode> \| undefined`		TreeSidebarMixin
root `HierarchyNode<NewickNode> \| undefined`		TreeSidebarMixin
treeHasBranchLengths `boolean`		TreeSidebarMixin
rowOrderIsCustom `boolean`	Whether the rows have been arranged away from the order they arrived in — what "Reset row order" is offered on. A written `layout` here; a display whose config seeds `layout` on load (the multi-sample variant displays' `colorBy` / `groupBy`) overrides it to compare against that seed, so the reset does not appear on a track nobody has touched.	TreeSidebarMixin

Methods

Member	Description	Defined by
contextMenuItems `() => MenuItem[]`	Items for the right-click menu, built from the column the click landed on. The position is captured when the menu opens rather than read inside the onClick, because `closeContextMenu` runs first when an item is clicked.	LinearMafDisplay
rowGeometry `() => MafRowGeometryParams`	Where the rows sit on screen: the resolved row height, plus the scroll offset and viewport that every rows layer places and culls against. One source for all of them — a layer spelling out its own geometry could quietly read the raw `rowHeight` sentinel, or forget the scroll and hang its markers a scroll-distance below the cells they annotate.	LinearMafDisplay
gpuProps `() => MafGpuProps`	Inputs to the main-thread GPU instance encoder. Changes here re-encode in the per-region encode autorun — no RPC roundtrip. Intentionally excludes `showAsUpperCase` (label-only) and view-shape props (rowHeight, rowProportion — driven by shader uniforms).	LinearMafDisplay
rpcProps `() => { subtreeFilter: string[] \| undefined; annotationDataActive: boolean; }`	Worker-fetch inputs that invalidate cached data when changed (tier-1, via MultiRegionDisplayMixin's `SettingsInvalidate` autorun → refetch). Row order is deliberately absent: no fetch argument depends on it any more, since the worker names rows by species and the main thread places them (`placeMafRegionData`). A reorder therefore re-places the cached payload — the heaviest in the plugin — instead of refetching it. `subtreeFilter` stays because it is a fetch argument, and the set is the only thing about the rows that is: the worker ships only the rows in it and scopes coverage/identity to them. It is sent as a set, never an order, so reordering inside a filter is still free. The discovered row set growing is deliberately NOT a key — see `setSamples` for why re-placement covers it. Nothing here may be fetch-derived. Keying on a value that is undefined until the first fetch lands and defined after flips the key on every track load, and `SettingsInvalidate` then throws away the region that just arrived — a measured 2 × `LinearMafGetAlignmentData` per region. Loop-safe but not free, which is exactly the case ARCHITECTURE.md's "`rpcProps()` loop trap and how to break it" is about. Pinned by `singleFetchPerRegion.test.ts`.	LinearMafDisplay
rowHoverInfo `(displayedRegionIndex: number, bp: HoverBp, rowIndex: number, bpPerPx: number) => {…} \| { ...; } \| { ...; } \| { ...; } \| undefined`	Resolve a hover hit on `rowIndex` at the cursor's genomic position (absolute uint32, per worker-output convention): an aligned base (`cell`) or a bridged/empty region (`empty`), each tagged with the sample label. Returns undefined when no fetched block covers the bp, the row is out of range, or the cell is a gap. `bp` carries both readings of the cursor (see `HoverBp`) because the cell and the interbase insertion marker are selected by different ones, and they differ on a reversed region.	LinearMafDisplay
rowNavigationTarget `(displayedRegionIndex: number, startBp: number, endBp: number, rowIndex: number) => {…} \| undefined`	Where `rowIndex` sits in its own genome across the reference bp range `[startBp, endBp)` — the locus a "open this species here" navigation targets. Undefined when the row has no aligned base in the range, when no fetched block covers it, or when the row's genome isn't loaded as an assembly (`Sample.assemblyName` unset), since there is then nowhere to navigate to.	LinearMafDisplay
frameHoverInfo `(displayedRegionIndex: number, bp: number, rowIndex: number) => { name: string; } \| undefined`	The CDS frame record covering absolute genomic `bp` (uint32) on display `rowIndex`, or undefined when no frame overlaps there (or no frames data is loaded). Gated on `annotationDataActive` not the strip toggle, so the gene name still reads on hover in codon view with the strip off. The species is matched by the same `src`→row projection the overlay draws with, so the tooltip and the strip can't disagree about which row a gene is on. `bp` is a base index — the caller passes `MafPointer.baseBp`, not a floored `gposFrac`, so this names the same base the row hover and the coverage tooltip do on a reversed region.	LinearMafDisplay
coverageTooltipBin `(displayedRegionIndex: number, position: number, bpPerPx: number, reversed?: boolean) => {…} \| undefined`	Build a per-position coverage tooltip bin (depth + SNP base counts) for the given absolute genomic bp + region index. Delegates the math to alignments-core's `buildCoverageTooltipBin` — same code path the alignments display uses. Insertions are reported separately via `coverageInsertionHit`, so they never mix into the depth/SNP table. Returns undefined when the region has no fetched data or depth is zero. `reversed` is the region's orientation, and the SNP snap below needs it for the reason alignments' `hitTestCoverage` does: the snap widens `position` into the bp the CURSOR'S PIXEL covers, and which side of `position` those bp lie on is what the orientation decides. `position` itself already comes through `basePaintedAt`, so it is the right base either way — widening rightward regardless searched the neighbouring pixel's bp on a flipped region, and reported a SNP the cursor was not over.	LinearMafDisplay
coverageInsertionHit `(displayedRegionIndex: number, gposFrac: number, bpPerPx: number) => CoverageInsertionHit \| undefined`	Hit-test an insertion bar in the coverage band at fractional genomic `gposFrac`. Returns the interbase summary (count + length range + interbaseDepth) when the cursor is on the bar, else undefined — drives the dedicated interbase tooltip, kept separate from the depth/SNP one.	LinearMafDisplay
codonHoverInfo `(displayedRegionIndex: number, bp: number, rowIndex: number) => CodonHit \| undefined`	The codon under the cursor on display `rowIndex` at absolute genomic `bp`, when the codon view is the active rendering: the species' codon + amino acid, the reference codon + amino acid, and the syn/nonsyn/stop classification. Reads the memoized `locatedCodons` the colored cells are drawn from, so the tooltip and the cell can't disagree and a mousemove costs a scan rather than a fresh codon resolution pass. Undefined off codon view or where no codon covers the row there.	LinearMafDisplay
trackMenuItems `() => MenuItem[]`		LinearMafDisplay
regionHasData `(displayedRegionIndex: number) => boolean`	Whether the tier the current zoom needs holds this region: crossing the summary↔detail threshold inside an already-loaded region wouldn't trip the bounds-based coverage check, so the answer is which map has it. The presence hook rather than `regionFetchKey`, which stays empty, because the two tiers cache side by side: the detail fetch keeps the summary records (`clearAlignmentData` runs one way only), and a summary/detail key would refetch the summary on every zoom back out.	LinearMafDisplay
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
isCacheValid `(displayedRegionIndex: number) => boolean`	Whether the data held for a region still answers the current view. Not a hook a display fills: a display states its rule as `regionFetchKey` (what a fetch now would produce) and `regionHasData` (did the last one store anything), and this compares the key against the one the region was fetched under. A subclass that changes what it fetches spells the change in the key, and one that forgets gets a redundant fetch rather than a cached answer for a zoom the data was never fetched at.	MultiRegionDisplayMixin
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
willClearTree `(next: S[]) => boolean`		TreeSidebarMixin

Actions

Member	Description	Defined by
setRowProportion `(n: number) => void`		LinearMafDisplay
setShowAllLetters `(f: boolean) => void`		LinearMafDisplay
setMismatchRendering `(f: boolean) => void`		LinearMafDisplay
setSamples `({ samples, treeNewick, samplesCanonical, }: { samples: Sample[]; treeNewick: string \| undefined; samplesCanonical: boolean; }) => void`	Receive the worker's `samples` + serialized Newick tree. `samplesCanonical` says whether that set is authoritative. Config- and tree-derived sets are: they're complete and identical on every region fetch, so they replace, and a species dropped from the config stops being a row. A sample-discovery set is not: it names only the genomes the fetched region's blocks contained, so it is unioned into the rows already known (`unionSources`). Replacing there dropped rows: a genome only one region aligns would stop having a row the moment another region reported its own set, and a region with no blocks at all (or the summary path, which never discovers) names none and so blanked every row. With either resolution the deepEqual guard makes this fire once and skips the redundant frozen-array reassignment (and downstream `sources`/instance-buffer recompute) on later scroll/zoom. The active `clusterTree` is set from the worker tree only when there's no custom arrangement — a reorder has cleared it and must keep it cleared until the user clears the layout. The guard covers the sample set only: a tree can change while the set doesn't (an edited `.nh`), and folding it in left `treeNewickVolatile` — and so what "Clear arrangement" restores — pinned to the first tree the session ever saw. A set that changes after one was already established invalidates nothing: the fetched rows name their species rather than a row index, so the placement autorun re-places them against the widened order and they are correct again without a refetch. This used to bump a `sampleSetGeneration` counter into `rpcProps()`, from a design where the worker narrowed each region's blocks to the client's sample list and so genuinely lost rows it had not been told about. It no longer takes one — the row set is config-derived or discovered per region in the worker, and the only thing the client sends is `subtreeFilter` — so the counter had become a pure refetch of every loaded region, once per newly seen genome, on exactly the discovery tracks that can least afford it.	LinearMafDisplay
setShowAsUpperCase `(arg: boolean) => void`		LinearMafDisplay
setShowCoverage `(arg: boolean) => void`		LinearMafDisplay
setShowAlignments `(arg: boolean) => void`		LinearMafDisplay
setCoverageHeight `(arg: number) => void`		LinearMafDisplay
setShowConservation `(arg: boolean) => void`		LinearMafDisplay
setConservationMode `(arg: "base" \| "codon") => void`		LinearMafDisplay
setRowIdentityMode `(arg: "heatmap" \| "none" \| "xyplot") => void`		LinearMafDisplay
setRowIdentityAutoZoom `(arg: boolean) => void`		LinearMafDisplay
setShowAnnotations `(arg: boolean) => void`		LinearMafDisplay
setShowTranslation `(arg: boolean) => void`		LinearMafDisplay
setColorByChromosome `(arg: boolean) => void`		LinearMafDisplay
setShowInversions `(arg: boolean) => void`		LinearMafDisplay
setConservationHeight `(arg: number) => void`		LinearMafDisplay
clearLayout `() => void`	Drop the custom arrangement and restore the worker's guide tree (the base `clearLayout` only clears it — the worker tree lives in `treeNewickVolatile`).	LinearMafDisplay
setFitToHeight `() => void`	Switch to fit-to-height mode: rows stretch to fill the track height. Seeds the `height` config slot from the current content height so toggling on doesn't jump, then `rowHeight = 0` makes `effectiveRowHeight` derive from it.	LinearMafDisplay
resizeHeight `(distance: number) => number`	Drag-resize the track. In fit-to-height mode the new height flows straight into `autoRowHeight`, so the rows stretch with the drag. With a fixed `rowHeight` the rows keep the size the user chose and the drag reveals more of them — the fixed height used to be scaled by the same ratio, which kept content and viewport locked together and made dragging a track taller unable to show a single extra species. The `resizing` flag that sits the letter overlay out of the drag is set on the track by the handle itself (TrackContainer / `MafBandResizeHandle`), not here — this action sees only individual deltas and can't tell the last one from the next, which is why it used to need a settle timer.	LinearMafDisplay
resizeCoverageHeight `(distance: number) => void`	Apply one drag delta to the coverage band. Reads the current height inside the action rather than taking an absolute target: `ResizeHandle` emits one delta per animation frame, so a component computing `renderHeight + delta` drops every tick that lands before React re-renders. Mirrors `resizeHeight`. Sits here rather than with its `setCoverageHeight` twin because the ceiling comes off `fitTargetHeight`, which is declared above this block.	LinearMafDisplay
resizeConservationHeight `(distance: number) => void`	Per-frame drag delta for the conservation band — see `resizeCoverageHeight` for why this reads the height itself.	LinearMafDisplay
sortRowsByBaseAt `(refName: string, pos: number) => void`	Reorder the rows by the base each species carries in the reference column at (refName, pos) — the MAF analogue of the multi-row painting's "sort rows by color here". Reads the placed region data already in hand, no refetch, and writes the order through `layout`, the channel clustering and the arrangement dialog write, so "Reset row order" undoes all three. Declines with fewer than two rows, and at a column no loaded region covers, for the reasons the other two displays' twins state: the empty write is not a no-op (`setLayout` drops the tree — here the guide phylogeny — whenever the row set changes), and every row reading "no base" writes back the order it already had.	LinearMafDisplay
setRowRendering `(rendering: RowRendering) => void`	Pick the row coloring, writing all three slots so exactly one is on. The exclusivity has to be written, not just displayed: the slots are independent booleans, `activeRowRendering` resolves a clash by precedence, and the menu used to offer them as separate checkboxes — so turning on color-by-chromosome while an identity plot was selected left a setting that was on, persisted into the session, and painting nothing. Selecting through here is what makes the tick the truth. A session saved before this (or hand-written config) can still carry two of them; nothing migrates, `selectedRowRendering` just reports the one that wins, and the next pick clears the rest.	LinearMafDisplay
setRpcData `(regionIndex: number, data: MafWireRegionData) => void`		LinearMafDisplay
placeFetchedRows `(rowIndexBySrc: Map<string, number>) => void`	Re-place every cached region against the row order now on screen. Driven by the autorun below, so a reorder repaints from data already in hand — the fetched rows name their species, so nothing about them is order-specific. Replacing the region objects is what re-runs the per-region encode.	LinearMafDisplay
setSummaryData `(regionIndex: number, records: MafSummaryRecord[]) => void`		LinearMafDisplay
setFramesData `(regionIndex: number, records: MafFrameRecord[]) => void`		LinearMafDisplay
setFramesGateBlocked `(blocked: boolean) => void`	Record whether the last frames read was declined as over budget. Set both ways by every fetch pass that reaches the annotation adapter, so zooming back in clears it without anything else having to.	LinearMafDisplay
clearAlignmentData `() => void`		LinearMafDisplay
clearDisplaySpecificData `() => void`		LinearMafDisplay
startRenderingBackend `(backend: MafRenderingBackend) => void`		LinearMafDisplay
fetchNeeded `(needed: { region: Region; displayedRegionIndex: number; }[]) => Promise<void>`		LinearMafDisplay
renderSvg `(opts: ExportSvgDisplayOptions) => Promise<ReactElement<unknown, string \| JSXElementConstructor<any>> \| Iterable<ReactNode> \| AwaitedReactNode>`	Dynamic import so the export path — and everything it pulls in — stays out of the bundle until someone actually exports.	LinearMafDisplay
setStatusMessage `(status?: RpcStatus \| undefined) => void`		BaseDisplay
setError `(error?: unknown) => void`		BaseDisplay
clearHoveredFeature `() => void`	Overridable hook (default no-op): drop whatever `hoveredFeature` reports. The writing twin of that getter, and what `installClearHoverOnViewportChange` calls. A display that STORES its hover owes an override; one that derives it from the live pointer (MAF, Hi-C, LD) owes nothing, and the default costs it nothing. Declared here so the clear can be installed for every display rather than remembered per display — forgetting it is the failure ARCHITECTURE.md's stored-hover section is about, and it used to be six closures at six call sites, which is six chances to omit one.	BaseDisplay
reload `() => void`	base display reload does nothing, see specialized displays for details	BaseDisplay
setScrollTop `(scrollTop: number) => void`	Clamped into `[0, scrollableHeight]`, so no caller has to remember the bound. Unbounded for a display that leaves `scrollableHeight` at its `Infinity` default.	TrackHeightMixin
setHeight `(displayHeight: number) => number`		TrackHeightMixin
expandToContentHeight `() => number`	Grow the track by exactly the content it is currently hiding, so a display scrolled over a taller stack ends up showing all of it. The track's resize handle runs this on a double click. `scrollableHeight` is the whole measurement — it is already every scrolling display's answer to "how much is off the bottom", so no display has to supply a second one. A display that doesn't scroll internally leaves it at `Infinity` and gets a no-op, as does one already showing everything (0). Routed through `resizeHeight` rather than `setHeight` so grow mode's override still gets to leave grow first; going straight to the slot would let the reactive height re-derive `grownHeight` and the double click would appear to do nothing.	TrackHeightMixin
setLoadedRegion `(displayedRegionIndex: number, region: Region, fetchKey?: string) => void`	The raw write behind `ctx.commitRegion`, and not what a fetch should call: a display naming its own span is the bug this family spent a release on, and going through the context is what makes that inexpressible — see RegionFetchContext. Direct callers are tests staging an already-loaded display. An action so callers after an async boundary stay in MST strict mode. Stamps the region with the fetch key its data came back under. `fetchRegions` passes the key it captured before issuing the RPC; the default reads it now, which is right for a caller holding the region already and wrong for anything resuming after an await, where the viewport may have moved under the fetch.	MultiRegionDisplayMixin
dropLoadedRegion `(displayedRegionIndex: number) => void`	Forget one region — for a display pruning what has scrolled off screen.	MultiRegionDisplayMixin
clearAllRpcData `() => void`	full reset: cancels fetch, clears error, loadedRegions, display-specific data, and the canvas-drawn flag. The too-large gate is derived (a pure function of the cached estimate × viewport), so it needs no explicit clear here — the fetch autorun re-measures at the new viewport and the verdict follows.	MultiRegionDisplayMixin
fetchRegions `(needed: IndexedRegion[], work: (ctx: RegionFetchContext) => Promise<void>) => Promise<void>`	Run a per-region fetch. The work callback calls `ctx.commitRegion` as it stores each region's payload, which is what marks it loaded — see RegionFetchContext for why this function no longer does that itself. Its only callers are the three helpers in `fetchEachRegion.ts`, which make that call for every display in the family; a display reaching past them owns both `ctx.isStale()` guards and the commit by hand, and none does. The fetch key is captured here, at issue, and carried into every commit — never re-read after the await. `ctx.isStale()` trips on a newer fetch or a cancel, not on a viewport that moved under a fetch that is still current, so a key read at commit time would stamp this data with a zoom it was not fetched at.	MultiRegionDisplayMixin
afterAttach `() => void`	installs the fetch-lifecycle autoruns (DisplayedRegionsChange, FetchVisibleRegions, SettingsInvalidate, ClearBlockingStateOnViewportChange)	MultiRegionDisplayMixin
setByteEstimate `(measurement: { bytes: number; viewport: GateViewport; }) => void`	The bytes half of a measurement alone, for a test staging a display. Production commits through `commitFetchBytes`.	RegionTooLargeMixin
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) => 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
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 goes on voting for a phase that is over. The viewport fetch (`runFetch`), the clustering run and a lent `createStopTokenRotation` are three of them on one field; before ADR-081 each blanked the field outright and the last one to finish decided what the other two were still saying. `isCurrent` is required and has no "node is alive" default, because alive is not the interesting question: 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()`, which is what every display gets for free through `ctx.statusCallback`; 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. Declared this early only so `runFetch` can put one on every `FetchContext`.	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`	Release an in-flight fetch's stop token 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
endFetch `(current: boolean, stopToken: StopToken) => 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: whoever superseded it — a newer `begin`, or `cancel` — already released this token.	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 stopToken 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 `activeStopToken`, `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
setRowHeight `(n: number) => void`	Pin a px row height. `0` is the fit sentinel, but enter fit mode through `setFitToHeight` instead — displays whose `height` getter is content-derived have to re-seed the slot on the way in, and that is what the action is for.	RowHeightMixin
setShowTree `(arg: boolean) => void`		TreeSidebarMixin
setShowBranchLength `(arg: boolean) => void`		TreeSidebarMixin
setShowRowLabels `(arg: boolean) => void`		TreeSidebarMixin
setLayout `(layout: S[]) => void`		TreeSidebarMixin
setClusterTree `(tree?: string \| undefined) => void`		TreeSidebarMixin
setLayoutAndClusterTree `(layout: S[], tree?: string \| undefined, provenance?: ClusterProvenance \| undefined) => void`		TreeSidebarMixin
setTreeAreaWidth `(width: number) => void`		TreeSidebarMixin
setSubtreeFilter `(names?: string[] \| undefined) => void`		TreeSidebarMixin
setRunClustering `(arg?: boolean \| undefined) => void`		TreeSidebarMixin
setClusterRegion `(arg?: string \| undefined) => void`		TreeSidebarMixin
setSortRowsBy `(arg?: RowSortSpec \| undefined) => void`	Trigger (or clear) a one-shot declarative row sort; consumed and reset by `setupRowSortAutorun`. A display's right-click item calls its own sort directly (instant, the data is already loaded); this is the session-level entry point.	TreeSidebarMixin
setHoveredTreeNode `(node?: HoveredTreeNode \| undefined) => void`		TreeSidebarMixin
setTreeCanvasRef `(ref: HTMLCanvasElement \| null) => void`		TreeSidebarMixin
setMouseoverCanvasRef `(ref: HTMLCanvasElement \| null) => void`		TreeSidebarMixin
openContextMenu `(info: Info) => void`		ContextMenuMixin
closeContextMenu `() => void`		ContextMenuMixin

LinearMafDisplay

Example usage#

Properties#

Volatiles#

Getters#

Methods#