feat(display): add save screenshot to file support

[FASTSHIFT]

Description of the feature or fix

Added screenshot saving file function to facilitate debugging of images during the drawing process.

Thanks to draw_buf, which unifies the data structure of the drawing buffer, it is extremely convenient to expand related functions later.

Notes

• Update the Documentation if needed.
• Add Examples if relevant.
• Add Tests if applicable.
• If you added new options to lv_conf_template.h run lv_conf_internal_gen.py and update Kconfig.
• Run scripts/code-format.py (astyle needs to be installed) and follow the Code Conventions
• Mark the Pull request as Draft while you are working on the first version, and mark is as Ready when it's ready for review.
• When changes were requested, re-request review to notify the maintainers.
• Help us to review this Pull Request! Anyone can approve or request changes.

[PGNetHun]

Sorry, but I think this PR should not be added to display and draw_buf, because:

1. display/draw_buf should contain only tightly related functions, and not any unrelated things. Meaning: do not add function to create a file in file system to write actual screen buffer into it. That should be done in a separate code (higher level of architecture).
2. -> Please avoid the "god object" anti-pattern!
3. There is already a feature to take screenshots: snapshot
4. Do not add a function that will be used (only) for testing / debugging
5. display/draw_buf should not know about FS module
6. if FS is not enabled in lv_conf.h, then saving would throw error

[XuNeo]

That should be done in a separate code (higher level of architecture).

How about adding utils directly in lvgl/src/others/utils/lv_utils.h

It's really useful to debug drawing issues, we have been using the same method since v8 together with obj screenshot.

The code is not only used for debugging but can also be used by application. For example, current app view can be saved to file system as an app preview image, and then be used in background task manager.

[PGNetHun]

Yes, if that is really needed, then it can be added to lv_utils.h; but FS-related calls have definitely nothing to do in display module / drawing layer (from archictecture perspective). If that function would save/duplicate the draw_buf into a separate memory address, then we could keep it there, but a file system saving function should not be there.
These not core functionalities should go definitely in separate modules, like lv_utils.h, etc.
Keep architecture and code structure clean, and separate core functionality from "higher-level" codes.

[kisvegabor]

What about making it a snapshot feature, like lv_snapshot_take_to_file? It would be more generic, not only for a display.

It would be even better to have a lv_draw_buf_save_to_file helper.

[XuNeo]

What about making it a snapshot feature, like lv_snapshot_take_to_file? It would be more generic, not only for a display.

It could also be really useful. Let's prepare it in another PR after #5487 is reviewed.

[PGNetHun]

Because file operations (especially saving many kilobytes to flash) can take many hundred miliseconds, it is better to duplicate the draw buf in memory, and saving that to file. Memory copy finishes faster, so even if source draw buf is not locked, the chance of “transient” state is less than saving the source directly to file system.

So, you have to decide: block drawing for a few ten-hundred miliseconds to save draw buf to filesystem, or duplicate it (more memory needed) and save that snapshot.

[lvgl-bot]

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

[XuNeo]

LVGL operates on a single thread, which prevents the use of its API in a separate thread for file writing. It is advisable to allow the user to determine the best approach, whether that involves duplicating a new draw buffer for a different thread or creating a static loading UI that displays saving file....

This API could serve as an initial step for users who wish to optimize it. Additionally, this API is not solely beneficial for debugging. It can also be utilized to save PNG decoded images as .bin images, for instance.