DotplotDisplay

Auto-generated from the @jbrowse/mobx-state-tree model in the source — see the developer guide for concepts. Provided by the dotplot-view plugin. View source.

Draws a SyntenyTrack as a dot plot inside a DotplotView.

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

Each section ends with the members a composed model contributes, linked to the page that documents them.

Properties

Member	Description
type `type: types.literal('DotplotDisplay')`
configuration `configuration: ConfigurationReference(configSchema)`

1 inherited property from one model

From BaseDisplay: id

Volatiles

Member	Description
rpcData `DotplotRpcData \| undefined`	RPC-computed feature data
instanceData `DotplotInstanceData \| undefined`	GPU-instance positions produced from rpcData, self-describing via embedded bpPerPx, with no colors in them. Rebuilt only when the data or the zoom changes; the palette is joined on top by the `geometry` getter.
geometryRegionSignature `string \| undefined`	The `regionSignature` the fetch behind `rpcData` was laid out under — its positions are cumBp over the displayed regions' order, so they draw only while the axes still show it (`geometryCurrent`). The synteny twin stamps the same thing.
fetchWarnings `ComparativeWarning[]`	What the last completed fetch had to say about itself, written with the data it describes (see `setRpcData`).
hoveredSegmentIdx `number`	Index into `instanceData`'s per-SEGMENT arrays of the line the pointer is nearest, or -1. The segment rather than the feature, even though the tooltip and the highlight are both about the feature: the feature index derives from this one (`hoveredFeatureIdx` below), and the CIGAR operator under the cursor derives from nothing else — a CIGAR-detailed alignment is a staircase of segments and the pointer is on one step of it. Same choice `LinearSyntenyDisplay.hoveredInstanceIdx` makes, where `getFeature` does the translating. It addresses `instanceData`, so it is dropped by BOTH writers of that — a zoom rebuilds the geometry without refetching.

12 inherited volatiles from 5 models

From BaseDisplay: error, statusMessage, statusProgress

From ComparativeFetchMixin: assembliesSwapped

From KeyedFetchMixin: loadedFetchKey

From FetchMixin: activeSignal, fetchGeneration, reloadCounter, statusWindow, fetchCanceled, fetchRotation

From LodTierInfoMixin: adapterHeaderRead

Getters

Member	Description
view `DotplotViewModel`	The plot this display draws into. One getter rather than a `getContainingView` cast per reader, the same way `LinearSyntenyDisplay.view` answers it. This names the view type even though the view names this display back (`dotplotDisplays`). That mutual reference resolves only because both model types are declared as `interface … extends Instance<…>` rather than `type … = Instance<…>` — see ADR-055.
displayKey `number`	Stable slot on the view-shared backend. Hashed from the node id, not taken from the track's index, so hiding or reordering a sibling can't hand this display another's buffer.
fetchLanded `boolean`	`ComparativeFetchMixin`'s hook: a fetch has completed (data is present, even if it mapped zero features). Not a feature-count test — an empty-but-finished fetch has landed, otherwise an empty plot spins the loading overlay forever.
hasDrawable `boolean`	`ComparativeFetchMixin`'s hook, answered with the instance geometry rather than `fetchLanded` or the `geometry` computed: `svgReady` is polled outside any reactive context, and a `geometry` read there recolors every segment per poll.
computedColors `Uint32Array<ArrayBufferLike> \| undefined`	Main-thread-computed per-segment colors — the gpuProps half of the rpcProps/gpuProps split. A color change recomputes this alone, without re-walking a single CIGAR. The opacity level is NOT read here. It rides the shader's `alpha` uniform (and `drawDotplotInstances`' param) off `DotplotView.dotplotRenderState`, so the slider is a redraw, not a recolor — the same split synteny makes. A field's fade is (`opacityFade`). Baking it in made every drag frame recompute this array, re-pack every instance and re-upload the buffer.
paintedRefNamePosition `RefNamePosition \| undefined`	Where a refName sits in whichever axis' assembly `color` names — `Assembly.getRefNamePosition`, alias-aware — which the chromosome-painting modes hand the palette out by. Undefined for every other mode, and while the assembly is still loading — the color function falls back to its hash there. It has to come from the assembly rather than from the features, because a color must not change with which chromosomes happen to be in view. The dotplot twin of `LinearSyntenyDisplay.paintedRefNamePosition`, off the two axes instead of two stacked levels: 'query' is the horizontal axis (the feature's own refName lane) and 'target' the vertical (the mate's).
paintedField `string`	The view's `colorField` as this plot paints it. 'reference' is the horizontal axis, the one diagonalize orders the vertical against, so it paints as 'query' — the dotplot twin of `LinearSyntenyDisplay.paintedField`, which resolves it per level.
trackColor `string`	This track's slot in the plot's palette, used by the `track` field. Assigned by the view, not locally: pinning a color on one track shifts which automatic slots its siblings can take.
trackId `string`
regionSignature `string`	Both axes' region sets as one string, from each axis' own precomputed `regionSignature` — the dotplot twin of `LinearSyntenyDisplay.regionSignature`.
geometryCurrent `boolean`	The held positions were laid out under the regions the axes show now. Re-ordering the chromosomes moves every cumBp coordinate and nothing rebuilds them main-thread, so without this the canvas draws the old layout for the debounce plus the round trip — every alignment against the wrong chromosome. `LinearSyntenyDisplay.geometryCurrent` is the same call.
geometry `{ colors: Uint32Array<ArrayBufferLike>; x1: Float64Array<ArrayBufferLike>; y1: Float64Array<ArrayBufferLike>; x2: Float64Array<ArrayBufferLike>; y2: Float64Array<ArrayBufferLike>; instanceFeatureIdx: Uint32Array<ArrayBufferLike>; segmentOps: Uint8Array<ArrayBufferLike>; instanceCount: number; baseH: number; baseV: number; } \| undefined`	Instance positions joined with the computed colors: what the backends upload and what SVG export draws. The view's upload autorun reads this, so a palette change re-uploads without rebuilding geometry. Undefined while the geometry describes a region order the axes have left.
hoveredFeatureIdx `number`	Index into `rpcData`'s per-FEATURE arrays of the alignment the pointer is over, or -1. Derived rather than stored, so it cannot disagree with `hoveredSegmentIdx` about which alignment that is. Not `instanceFeatureIdx[i] ?? i`: an out-of-range segment index reads `undefined` there, and falling back to the raw index would answer with a different feature rather than with nothing. Same reasoning as `LinearSyntenyDisplay.getFeature`. Gated on `geometryCurrent` with the drawing: a reorder does not go through `setRpcData`, so a surviving index would name the wrong alignment over a canvas drawing nothing.
tooltipLines `string[] \| undefined`	The hovered feature's tooltip, as lines, or undefined when nothing is hovered. The dotplot twin of `LinearSyntenyDisplay.tooltipLines`; both feed `ComparativeTooltip`, which renders lines as text nodes — see `getDotplotTooltipLines`.
hoveredFeatureHighlight `DotplotHoverHighlight \| undefined`	The hovered feature redrawn over the canvas: an SVG path of its segments in plot px, plus its own packed color as CSS. The hover shading is entirely this getter; neither renderer draws it. Synteny boosts alpha and darkens rgb per fragment from a `hoveredFeatureId` uniform, which costs an instance lane, a uniform, a hand-written Canvas2D twin of the same arithmetic, and a broken color run in `drawDotplotInstances`' batcher. Restroking one feature — a handful of segments — over the shared canvas needs none of that, and is backend-agnostic by construction: it draws the same over the GPU canvas and the Canvas2D fallback because it never asks which one painted. `renderSvg` deliberately does not draw it — an off-screen export has no pointer, and a transient hover has no business in a figure. The cue is opacity + width, not hue: the plot's own `alpha` slider routinely sits at 0.2, so restroking opaque and a few px wider is exactly synteny's "the hovered one goes solid". Nothing here picks a highlight color, because every hue is already in use — category10 paints the chromosome modes, and red/blue/black are the strand and default schemes. Recomputes on pan (through `plotTransform`'s `viewBpH`/`viewBpV`), so the highlight stays on its feature, and only while something is hovered. `plotTransform` rather than `dotplotRenderState`, which carries `alpha` and `lineWidth` too — an opacity drag would rebuild this path once a frame for a value it does not read.
fetchRegions `Region[]`	The h-axis fetch window: the visible content blocks expanded by the shared pan buffer and snapped outward to a buffer-sized grid, so a pan within the buffer neither refetches nor exposes an unfetched strip, and zoomed out it collapses to the whole displayed region. The v axis is deliberately not scoped: the fetch is one-dimensional (h regions in, every mate out), so a vertical pan needs no data the h window didn't already bring, and must never trigger a refetch. Unlike synteny, nothing culls this window again in the worker — executeDotplotFeaturesAndPositions maps every feature it is handed — so the window's only job is to be a superset of what's on screen.
viewSignature `string`	`KeyedFetchMixin`'s hook, this display's half of `currentFetchKey`: the fetch-input signature (see fetchKey.ts) for the view's current state. The mixin appends the settings and adapter axes. Reactive: recomputes when either axis's zoom or displayed-region order/orientation changes, or when a pan carries the h axis into a new snapped fetch window. As a computed it only notifies when the string itself changes, which is what lets the fetch autorun track it and stay quiet through sub-buffer pans.
lodTier `LodTier`	The detail tier this plot's fetch asks the adapter for. Resolved here on the main thread, not adapter-side from `bpPerPx`, so it is part of `currentFetchKey` — see `resolveLodTier`. Both axes feed it: CIGAR detail is worth drawing when a block is wide on either one, so dropping to the no-CIGAR tier is only safe once both are past the threshold. The tier the adapter will serve once `lodTierInfo` has landed: a file with no coarse tier is 'fine' at any zoom, and the threshold is clamped up to the file's `--coarse` bound.
displayPhase `DisplayStatusPhase`	The display's own mutually-exclusive state, the way every LGV display publishes one — so `AppReadyMarker` counts this display's fetch, and the app stops reporting itself ready over a plot that is still working. Ranked by `comparativeDisplayPhase`, off the shared canvas's `surfaceReadiness` and this display's own fetch state. `DisplayStatusPhase`, not `DisplayPhase`: the view owns the rendering backend, so this display can never be the one to report a backend failure.
warnings `ComparativeWarning[]`	Per-render fetch warnings, plus the load-time reversed-assembly hint.

26 inherited getters from 5 models

From BaseDisplay: parentTrack, RenderingComponent, DisplayBlurb, adapterConfig, isMinimized, hoveredFeature, featureNoun, featureWidgetType, plotKeys, plot, plotExamples, configDocsUrl

From ComparativeFetchMixin: loading, refetching, svgReady

From KeyedFetchMixin: dataSuperseded, currentFetchKey, dataCurrent

From FetchMixin: isLoading, isLoadingOrCanceled, fetchInert, awaitingPrerequisite, awaitingDependentData, settingsFetchInputs

From LodTierInfoMixin: adapterHeader, lodTierInfo

Methods

Member	Description
renderSvg `(opts: ViewExportSvgOptions & { theme?: ThemeOptions \| undefined; }) => Promise<Element \| null>`

5 inherited methods from one model

From BaseDisplay: renderingProps, trackMenuItems, liftPlot, plotProblems, plotWrites

Actions

Member	Description
setRpcData `(data: DotplotRpcData, warnings: ComparativeWarning[], regionSignature: string) => void`	Commits a fetch result and the warnings it raised, tagged with the key it was fetched for. One action, not three: the warnings describe this result, so writing them separately let a failed refetch leave the last result's warnings standing over data they no longer describe, and each extra action is another round of the view's warning/upload observers per RPC completion. Same reason `LinearSyntenyDisplay.setRpcData` takes its feature and instance data together. The loading flags are deliberately NOT touched here: this runs as `installComparativeFetchAutorun`'s `commit`, whose `finally` clears `isLoading` and the status line under the same staleness guard. `setError` is not overridden either: the two callers that set one (the fetch skeleton's `catch`, `afterAttach`'s) already log it, so the override this display used to carry printed every fetch failure twice — and had to special-case `undefined` because the skeleton clears the error through the same setter before every fetch.
setInstanceData `(data: DotplotInstanceData \| undefined) => void`
setHoveredSegmentIdx `(idx: number) => void`	Written by the view's `setHoveredFeature`, which points the whole plot's hover at one hit — never per display from a component, so the N writes land in one MobX batch.