Thanks for the reply. I have some more questions.
1)
LVGL can do both. It can use SDL in order to render within a normal X11 window, or it can render to the framebuffer directly.
It can do both ways without loosing any features? If so, why use SDL or x11?
2)
@kisvegabor here
The person who issue with writing fast to screen says they can write directly to framebuffer with no issues. Why would there be any issues with LVGL? Is LVGL sort of a huge library now that it’s hard to find where the inefficiency is? I am assuming LVGL is just a wrapper and doesn’t add any delays itself to writing process to frame buffer.
3)
The same person was asking for 60Hz (1/60 = 0.16 milliseconds per screen refresh). Does linux kernel framebuffer only support 60Hz and not 120Hz or more? or is this an LVGL limitation?
4)
What makes chart widget not be optimal for this task? Are there delays or it doesn’t have a good queue system for example for receiving data? I see JavaScript libraries that claims to be able to to millions of data points per second so wondering what makes the same job very hard for LVGL?
5)
You suggested to use Canvas. Is that because it is good at taking data points faster? I am assuming write operation speed to framebuffer is same whether it comes from charts widget or canvas widget. I am also assuming canvas widget is more efficient in receiving data points and sorting them before shooting them to framebuffer VS chart widget - is that why I should go for canvas? (my knowledge of canvas, chart graphics is limited as I still see it all as pixels).
6)
If we develop our program on Ubuntu using LVGL for example, is that portable to Android or iOS or parts of it that relate to LVGL? Wondering if we can plan for that ahead of time.
7)
How are these examples displayed? The demo stress test is impressive. Are these actually running on a linux server and then projected as mirror images JavaScript and then to browser? I understand LVGL is just to write to framebuffer and not even to a monitor.
Thanks,