Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chart can't display full range #7564

Open
ellchr00 opened this issue Jan 7, 2025 · 1 comment
Open

Chart can't display full range #7564

ellchr00 opened this issue Jan 7, 2025 · 1 comment

Comments

@ellchr00
Copy link

ellchr00 commented Jan 7, 2025

LVGL version

v9.2.2

Platform

VSCODE in MinGW but irrelevant

What happened?

Using a chart (linechart) and setting the range to int32_t MIN and int32_t MAX and a series consistent of 0's does not draw the line in the middle. of the chart window.

I followed the issue into lv_chart.c and found the following problem: In the calculations there will be a wrap around depending on the chart drawing area and it is not possible to draw the full 4 byte range like this.

847: int32_t y_tmp = (int32_t)((int32_t)ser->y_points[p_prev] - chart->ymin[ser->y_axis_sec]) * h;
848: y_tmp = y_tmp / (chart->ymax[ser->y_axis_sec] - chart->ymin[ser->y_axis_sec]);

where h in my case are 133 (pixels) , with a y_point being 0 and chart->ymin being −2147483648.
y_tmp will be 1 instead of the expected 66 -> therefore the line will be at the bottom of the window instead of the middle

multiple instances of said calculations can be found within the code .....

I don't know what the best solution of this problem is .... either using int64_t (not available on all platforms) or via float (undesired performance issue ?)

What is your take on the problem ? Am I the only one experiencing it ? Looking forward to an answer ...

How to reproduce?

No response

@kisvegabor
Copy link
Member

kisvegabor commented Jan 16, 2025

Hey,

Thank you for reporting and tracking this issue.

I don't know what the best solution of this problem is .... either using int64_t (not available on all platforms) or via float (undesired performance issue ?)

I agree with this. None of these solutions are ideal. 🙁

I wonder if we can eliminate the need for -2M..2M range, for example by scaling down the input data. E.g. can you just divide all values by 10k and use a +/- 200 range?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants