Awesome tool - thanks for releasing it, it is very good.
I have been testing it out with some time series science data - a line chart of values with datetimes on the x axis and I think the renderer struggles if you have large amounts of datetime data of the order of hundreds of datapoints per second, plotting many hours of data, so millions of data items to plot
It ends up looking like this - the x axis datetimes are getting quantised i think
And it should look more like this without the gaps/quantisation by forcing the data to a lower rate:
My AI coding companion reckons this on the cause of the issue:
looks like a bug in the xy charting library (v0.0.6): its WebGL client reconstructs each point's pixel position from a shared GLSL decode helper, xyDecode(encoded, meta) = encoded/meta.y + meta.x, entirely in 32-bit float. A real calendar-date epoch (~1.7e12 ms since 1970) exceeds f32's ~2^24 integer precision budget, so every point in a narrow window rounds to the same pixel column. This affects every mark type (line/scatter/step/stairs/segments all funnel through the same shader)
Awesome tool - thanks for releasing it, it is very good.
I have been testing it out with some time series science data - a line chart of values with datetimes on the x axis and I think the renderer struggles if you have large amounts of datetime data of the order of hundreds of datapoints per second, plotting many hours of data, so millions of data items to plot
It ends up looking like this - the x axis datetimes are getting quantised i think
And it should look more like this without the gaps/quantisation by forcing the data to a lower rate:
My AI coding companion reckons this on the cause of the issue: