EEZ Studio Dashboard LineChart: Test Duplicate X Values at the Tail and in the Middle

EEZ Studio's Dashboard LineChart documentation asks for an increasing X value for each new point. Duplicate X values therefore deserve attention at the producer boundary. In the inspected source, equal X values also take different paths depending on whether the matching point is last in the stored list.

The LineChart reference supplies the increasing-X contract. The pinned Plotly widget implementation supplies the diagnostic behavior below, at EEZ Studio v0.29.0 commit 3000161d09d40a5c1dc2477ddc30b38037b3a612.

These duplicate-key cases are outside the documented monotonic input contract. They explain surprising results; they are not an advertised update-by-X API on which to build a new acquisition design.

Equality has a position-dependent branch

After the chart execution state exists, the action evaluates the incoming X value and the line values. It searches the stored points in order.

A smaller X is inserted before a larger existing X. An equal X enters another branch: the existing line values are replaced only when the matching point is not the last element. That replacement marks the incoming point as inserted.

When equality occurs at the last element, the loop breaks without setting the inserted flag. The later fallback appends the incoming point. The difference is caused by the explicit last-element condition, rather than by a renderer deciding how to draw overlapping coordinates.

Compare two otherwise identical point buffers

Use a proposed single-line fixture with established points (1,10) and (2,20), where each pair represents X and Y. Give the chart a positive Max points value of at least 3 so that trimming does not conceal the first result.

For the first case, provide (1,99). The matching X is not last, so the source predicts [(1,99),(2,20)]. For a separate fresh case, provide (2,99). The match is at the tail, so the predicted buffer is [(1,10),(2,20),(2,99)].

Inspect the stored values or an instrumented trace as well as the plot. Two points at the same X may be difficult to distinguish visually, especially if their Y values are close. A screenshot that looks plausible cannot prove that the buffer contains one point per X.

The initial execution creates the chart state and returns. Ensure the fixture has reached its established-state input path before interpreting an absent point as an equality issue. Keep reset inputs out of the comparison because reset takes a separate branch that clears the stored values.

Capacity can hide the duplicate's cost

After insertion or append, the implementation removes elements from the front while the stored length exceeds Max points. Repeating the tail case with Max points set to 2 therefore predicts [(2,20),(2,99)]: the new duplicate consumes a slot and the earlier X=1 point is removed.

That matters when diagnosing a shorter-looking history. The configured capacity may still be obeyed even though it is occupied by fewer distinct X coordinates. Raising the limit would postpone eviction without resolving the producer's duplicate-X behavior.

Use a small, positive capacity for this diagnostic. Malformed or negative limits are a separate input-validation problem and are unnecessary to expose the equality branch.

Repair the input contract deliberately

If X represents a timestamp, examine whether successive producer events can share the same timestamp resolution. If repeated X values represent corrections to an earlier measurement, decide how those corrections should be consolidated before feeding an append-oriented chart.

Do not silently add tiny offsets merely to make the line look right unless the application explicitly defines that transformation. An altered coordinate can misrepresent elapsed time. A sequence coordinate may be appropriate for some displays, but it changes the meaning of the axis and should be labeled accordingly.

The implementation separately debounces its update notification with a requested 16-millisecond timer. That affects when the view is notified; it does not turn the insertion algorithm into a consistent equal-key replacement operation. No chart was executed here. The useful outcome is a discriminating two-case fixture and a clear reason to enforce the documented increasing-X policy upstream.