2020-03-24 01:48 AM
Hi,
I'd like to know if there is a way to reduce the computing power required by the scroll List widget to redraw itself considering that it's incredibly slow on my board (note that it works just fine in the simulation). It does spread almost over the whole screen ( 480 x 800px) which makes it very slow (everything goes faster when the widget takes up less space). Is there a way to reduce the 'nb of steps' for instance, even if it's at the cost of fluidity (in the sense that instead of redrawing it for every px moved, just redrawing it for every two pixels).
Thanks in advance
Solved! Go to Solution.
2020-03-26 02:29 AM
Hi,
You must be aware that in case of scroll list, at each animation step the entire area of the scroll list is redrawn so is the display.
If the scroll list moves 10 pixels up for example then the entire corresponding area in the frame buffer will be refreshed 10 times thus raising the memory bus bandwidth (usually ChromArt is in charge of updating the frame buffer through FMC, only assumption here as you did not mention your setup).
But this FMC is also accessed by the LTDC to send 60 times per second the frame buffer to display either is changes or not.
When the LTDC is sending the framebuffer to the display a lock mechanism is used to prevent any write operation and thus prevent flickering.
The "slow" animation you observe is probably due to the skipping of some animation steps that were requested during the LTDC lock, this frame are then replaced by the next one and thus lost. There is no FIFO for frames, only 2 frame buffers, one "front frame buffer" for the frame being sent to display, the other "back frame buffer" for the next frame to be displayed.
So what you observe is completely expected, the smaller the widget the smoother the animation.
What you observe in the simulator is processed on your PC, with its GPU, its RAM, etc, this is not supposed to be what you see on you device !
You should either reduce the size of your scroll list widget as much as possible or maybe adapt the "animation" parameter (in the source code directly, not in the designer), see https://touchgfx.zendesk.com/hc/en-us/articles/360018095032-Scroll-List and the API description, for example:
You need to investigate how the animation steps are set in your widget and maybe adapt it.
Best regards,
Nicolas
2020-03-26 02:29 AM
Hi,
You must be aware that in case of scroll list, at each animation step the entire area of the scroll list is redrawn so is the display.
If the scroll list moves 10 pixels up for example then the entire corresponding area in the frame buffer will be refreshed 10 times thus raising the memory bus bandwidth (usually ChromArt is in charge of updating the frame buffer through FMC, only assumption here as you did not mention your setup).
But this FMC is also accessed by the LTDC to send 60 times per second the frame buffer to display either is changes or not.
When the LTDC is sending the framebuffer to the display a lock mechanism is used to prevent any write operation and thus prevent flickering.
The "slow" animation you observe is probably due to the skipping of some animation steps that were requested during the LTDC lock, this frame are then replaced by the next one and thus lost. There is no FIFO for frames, only 2 frame buffers, one "front frame buffer" for the frame being sent to display, the other "back frame buffer" for the next frame to be displayed.
So what you observe is completely expected, the smaller the widget the smoother the animation.
What you observe in the simulator is processed on your PC, with its GPU, its RAM, etc, this is not supposed to be what you see on you device !
You should either reduce the size of your scroll list widget as much as possible or maybe adapt the "animation" parameter (in the source code directly, not in the designer), see https://touchgfx.zendesk.com/hc/en-us/articles/360018095032-Scroll-List and the API description, for example:
You need to investigate how the animation steps are set in your widget and maybe adapt it.
Best regards,
Nicolas
2020-03-30 06:25 AM
Thanks for your answer.