ReadonlybaseReadonlyelementReadonlytopRelative height weight within the chart (price=1, volume≈0.3).
Why the backend is painting through its 2D fallback rather than the path it was chosen for, or null. Read by the chart after each frame; the answer is a property of the device, so it is the same for every pane sharing it.
The 'right' scale: the pane's primary axis, and the one a series maps to
unless it names another. A getter over a field rather than a plain readonly
property because moveSeriesScale swaps the two side scales, and the range,
mode, margins, tick size and formatter all belong to the axis being moved.
The scales that draw a ladder: the right one and, once something uses it, the left. The hidden overlay scale is deliberately not here.
That scale is positioned by whoever created it and by nobody else. A volume
histogram sitting in the bottom fifth of the price pane is an overlay with
marginTop: 0.82, and a chart-wide plot-margin change that swept it up
with the visible axes replaced that 0.82 with the dialog's number: the bars
grew to fill most of the pane, and putting the dialog back where it started
wrote 0.1, not the 0.82 nobody had recorded. Destructive and unrecoverable,
from a control that only claims to move the plot inside its own axes.
Whether this pane currently holds primitive.
Topmost primitive hit at media-px (x,y) relative to this pane's plot.
Move every series on one side's scale to the other side, axis and all.
The two scale objects are swapped rather than their state copied across: the range, mode, margins, tick size and any custom formatter are all properties of the axis being moved, and copying would have to enumerate every one of them (and gain a field each time one is added). What is left behind carries nothing, so it is reset: keeping its range would label the vacated strip with a ladder for prices that are no longer on that side.
Refuses when the target side already carries series. One side draws one axis, so a move onto an occupied side could only mean stacking two ladders in one strip or silently sending the sitting tenant the other way, and neither is what "move this axis to the left" asks for.
Paint background + grid + series + axes on the base canvas, or into
target when given: the vector export runs this exact pass into a
serialising context, so what it produces is the frame and not a
re-description of it. Only the pane's own canvas is cleared first; a
target starts empty by construction.
Optionaltarget: CanvasRenderingContext2DTop (overlay) canvas: top-layer primitives + crosshair. Cheap repaint on
cursor moves. cross.x is the shared plot x (vertical line, drawn in every
pane for a global crosshair); cross.yLocal is the price-line y for the
hovered pane only (null elsewhere); cross.showTimeTag draws the date tag
on the bottom pane's axis strip.
Optionaltarget: CanvasRenderingContext2DPrimitives attached to this pane, in draw order.
Whether this scale's price-per-bar ratio is currently pinned.
The scale a price quoted for this pane belongs to: the crosshair readout, the price on a click or a drag, and the chart's coordinate API all mean this one. It is the right scale in every layout that has not moved an axis.
Remove a primitive if present; returns true if it was found.
The scale for an id, created if this pane has never used it. A host acting on one axis (a price-axis menu) needs the scale a side would use, not only the ones series happen to occupy; an empty scale draws nothing, because both the axis strip and the left column are gated on a scale having been measured.
The price scale a series maps to (for the series handle's priceScale()).
Every scale this pane has actually created. The left and overlay scales are built on demand, so a caller applying a pane-wide setting (plot margins, label precision) needs the live set rather than all three ids.
Swap the backend for the rest of the session: the old one releases its resources, the new one takes the base canvas and its context and is told the current size, so it is ready for the very next frame. The chart calls this for every pane at once when a GPU backend degrades, so a chart never paints half its panes one way and half the other.
Lay the pane out at a size without touching its canvases. The vector
export paints at a size of the caller's choosing and then puts the live
size back; resizing a canvas clears it, so going through resize would
blank the screen until the next frame.
Pin (or release) the price-per-bar ratio of one scale, against the geometry in force right now. A locked scale is manual by definition: autoscaling it would re-fit the data every frame and undo the ratio being held.
Locking a scale nothing has measured does nothing: there is no ratio to hold yet, and switching it to manual would strand it on the 0..1 placeholder with nothing left to measure it. Returns whether the scale ended up in the state asked for; releasing always succeeds.
Give every scale on this pane its plot height. Height is a layout property, but it used to be set only inside the autoscale pass — so any y↔price conversion before the first paint divided by zero and returned ±Infinity. Layout is when the height is actually known.
True when some series on this pane maps to the named scale.
backenddefaults to the 2D one so a pane built on its own (tests, a host composing panes by hand) paints the way it always has; the chart passes whatever itsrendereroption resolved to.