@finchart

Appearance

Documentation / @finchart/core / index / Viewport

Interface: Viewport ​

Defined in: packages/core/src/data/types.ts:196

The data range currently visible on screen.

Properties ​

endX ​

endX: number

Defined in: packages/core/src/data/types.ts:198

height ​

height: number

Defined in: packages/core/src/data/types.ts:200

screenXScan? ​

optional screenXScan?: () => (x) => number

Defined in: packages/core/src/data/types.ts:219

A factory that opens a pass for screen-place lookups. If absent, x is the screen place (continuous coordinate space, the default). A bar-index coordinate space supplies this — decimation that buckets by x (M4Decimation, LttbDecimation) has to bucket in that same space to line up with the screen.

Why a factory and not a function: a cursor that speeds up lookups has to be owned by a single scan. Share one function and you share the cursor too, so a sweeping consumer and a point-by-point consumer trample each other. Whoever opens the pass holds the cursor, and it dies when the pass ends.

Why this travels with the range (startX, endX): two consumers (drawing, the value axis) both ask "what's visible," and if the definition splits, the same viewport gets different answers and the cache goes out of sync.

Returns ​

(x) => number

startX ​

startX: number

Defined in: packages/core/src/data/types.ts:197

width ​

width: number

Defined in: packages/core/src/data/types.ts:199

xEpoch? ​

optional xEpoch?: number

Defined in: packages/core/src/data/types.ts:229

How many times the x mapping has recounted indices. Screen place is a domain value of the mapping, so it goes stale on a rebuild — another series's setData changing the merged x list shifts my places even though my data didn't change. This count is the invalidation key for the place cache. Only travels together with screenXScan — a continuous mapping has nothing to count.