pub struct ColorBarOptions {}Expand description
The colourbar — and, because it owns the z axis, the chart’s only z scale.
axis is the whole point. It is the same AxisOptions the four chart
axes use, so scale (including Logarithmic), min / max,
major_spacing, minor_count, label_style (including
LabelFormat::Power), tick, and title_option all mean here exactly
what they mean there — and tick generation, label formatting, and log
handling are the same code, not a parallel implementation that drifts.
axis.min / axis.max are the authority on the z range. A helper may fill
them in from matrix statistics, the way AxisOptions::auto_ticks fills in
spacing, but nothing else stores a z range.
Consequences worth stating, because they are decisions and not accidents:
- A
Heatmap/Contour/HeatmapContourseries requires this to beSome. Without it there is no z range and no colormap anywhere, so there is no value to draw — the renderer rejects the series rather than inventing one. - To hide the bar, set
visible: false. The options stay, the field still renders, and the band is given back to the data area. - There is therefore one z scale per chart. Several heatmaps in one chart share it; two colourbars with different scales is out of scope.
Fields§
§visible: boolFalse draws nothing and reserves no band. Field series still render.
side: SideWhich margin the bar occupies. Left / Right give a vertical bar,
Top / Bottom a horizontal one, and this alone decides which.
The discrete half of the bar’s placement, the way
Legend::corner is for the legend box;
offset_x / offset_y are the continuous half.
thickness_px: f32The strip’s short dimension: width for a vertical bar, height for a horizontal one.
gap_px: f32Space between the data area and the strip.
length_frac: f32Strip length as a fraction of the data area’s length along its side.
align: BarAlign§offset_x: f32Free offset from the side + align anchor, in screen pixels — the
same contract as Legend::offset_{x,y} and the title / label offsets:
margin-noncontributing, so nudging the bar moves it without
reflowing the data area under the pointer.
This is where a drag accumulates. Without it the bar had no continuous position at all, which is what kept it out of the selection / drag / resize machinery every other piece of chrome already uses.
offset_y: f32§colormap: ColorMap§nan_color: ColorColour for z values the ramp cannot place: NaN, and non-positive z on a logarithmic colourbar. Fully transparent by default — “missing” reads as absent rather than as some particular value.
border_color: Color§border_width: f32§axis: AxisOptionsThe z axis. See the type docs — this is the SSoT for the z range.
Implementations§
Source§impl ColorBarOptions
impl ColorBarOptions
Sourcepub fn normalized_z(&self, z: f64) -> Option<f32>
pub fn normalized_z(&self, z: f64) -> Option<f32>
Where z falls on the ramp, in [0, 1], or None when the ramp cannot
place it — draw those with Self::nan_color.
This is the z→colour normalization. The CPU colourbar strip and the GPU field sampler both go through this formula, so a cell and the tick beside it cannot disagree about what a value looks like:
linear: t = (z - min) / (max - min)
log: t = (log10 z - log10 min) / (log10 max - log10 min)clamped to [0, 1]. None for NaN, for a non-positive z on a
logarithmic bar (no logarithm to take), and for a degenerate range.
Two things it deliberately does not do:
- It does not clamp an unplaceable value to an endpoint. “Missing” and
“smallest” are different facts, and
nan_coloris how the second one stays distinguishable. - It does not apply
axis.inverted. Inverting an axis moves where a value is drawn; it does not change which colour that value has. The strip’s screen ends swap, its ramp does not reverse.
Sourcepub fn color_for_z(&self, z: f64) -> Color
pub fn color_for_z(&self, z: f64) -> Color
The colour for z: the ramp where it can be placed, nan_color where it
cannot.