Point markers on a line series stop rendering when using per-point colors

[whis]

Lightweight Charts™ Version: 5.0.8

Code to reproduce:
https://jsfiddle.net/dbto9v83/9/

Actual behavior:

When assigning a custom color to each data point, point markers render only up to the last data point that shares the same color. As soon as the series encounters a point with a different color, all subsequent markers stop rendering.

Additionally, the line color appears to update one bar later than expected.

Expected behavior:

Point markers should render for all data points, regardless of whether each point has a different color.

Screenshots:

[SlicedSilver]

When assigning a custom color to each data point, point markers render only up to the last data point that shares the same color. As soon as the series encounters a point with a different color, all subsequent markers stop rendering.

Agree that this is bug

Additionally, the line color appears to update one bar later than expected.

I think this is working as expected though.

[whis]

Additionally, the line color appears to update one bar later than expected.

I think this is working as expected though.

Is it really working as expected?

If I want to color the line based on positive or negative slope, it means I’d have to apply the color to the previous data point instead of using something simple like currentColor = close > open ? green : red. That feels unintuitive. I would expect the line segment to use the color I assign for the current point - drawing from the previous point to the current one, rather than applying that color to the segment leading into the next point in the future.

[SlicedSilver]

You raise a valid point, and I definitely see the logic in your interpretation (coloring the segment leading into the data point).

When I say it is "working as expected," I mean that the library was intentionally designed with a specific convention: a data point "owns" the line segment that starts from it.

There are two ways to interpret how a line segment connecting Point A and Point B should be styled:

1. Backward-looking: Point B dictates the style of the line coming from A (your expectation).
2. Forward-looking: Point A dictates the style of the line going to B (current implementation).

We chose the Forward-looking approach because it aligns better with time-based styling, such as session highlighting. For example, if you want to color a "Pre-market" session that starts at 08:00, you would apply the color to the 08:00 data point, and the line extending from that point onwards will carry that color. If we used the backward-looking approach, you would have to style the next point (08:05) to affect the line starting at 08:00, which becomes difficult to manage when dealing with irregular time gaps or missing data.

While I understand this makes "slope coloring" slightly more complex (requiring you to apply the calculated color to the index i-1 rather than i), it prevents the inverse complexity for session/time-based coloring. Since we had to pick one convention for the renderer, we stuck with the forward-looking approach.

Colouring based on session is a more common use-case than colouring based on slope (which can be considered redundant information anyway since the slope is clearly visible as up or down already).

I hope that clarifies the design choice here! We will proceed with fixing the bug regarding the markers stopping, but the line coloring behavior will likely remain as is (so we don't introduce a breaking-change).

Footnote:

• Timestamps on financial data refers to the starting point of period (easier to think about this in candles since lines appear continuous when they are actually just joining the dots between points).
• A more accurate line plot would actually use the WithSteps setting for lineType but people generally prefer how the 'Simple' (default) setting looks.

[whis]

Colouring based on session is a more common use-case than colouring based on slope (which can be considered redundant information anyway since the slope is clearly visible as up or down already).

I’d say that’s highly debatable. Based on my experience developing for third-party trading platforms at both retail and institutional levels for over a decade, I’d actually argue the opposite — slope-based coloring is a very common and useful feature. But I understand that time-based indexing introduces additional difficulties and must be accounted for here.

Edit: Adding a property on the line series to toggle between backward-looking and forward-looking coloring could satisfy both use cases. It might be worth considering if more users raise the same concern.

I hope that clarifies the design choice here! We will proceed with fixing the bug regarding the markers stopping, but the line coloring behavior will likely remain as is (so we don't introduce a breaking-change).

Yes, absolutely! Thank you for the thorough explanation and the reasoning behind the design choice. I'll adapt to this behavior on my side. Thanks again for the clarification.