Keep history of LVGL benchmarks and build attributes (BSP-797)

[PetrESP]

Definition of done:

• Visual representation of parameters with history
  • LVGL benchmarks
  • Binary size
  • Internal flash usage
  • Memory region representation in %
• Must be available publicly
• Results are linked to commit hash

[github-actions]

Hi @PetrESP! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Based on the knowledge sources provided, I can share what currently exists in the ESP-BSP ecosystem regarding LVGL benchmark tracking, though the sources don't fully address all the requirements in the GitHub issue.

What Currently Exists

The ESP-BSP repository already has a benchmark tracking system with some of the requested features:

• LVGL benchmark results are stored per board (e.g., ESP32-S3-LCD-EV-Board, ESP32-P4 Function EV Board, M5Stack CoreS3, M5Dial, ESP-BOX-3) and include metrics like Avg. CPU, Avg. FPS, render time, and flush time. [ESP32-S3-LCD-EV-Board README]

• The benchmark example (display_lvgl_benchmark) is integrated into CI: it runs on selected PRs (via a "Run benchmark" label) and after merges to master. Measured values from a PR are compared against the master branch and posted as a comment highlighting differences. Benchmark results for the master branch are stored in BSP releases. [Display LVGL Benchmark README]

Gaps vs. Your Requirements

The knowledge sources do not contain information about the following requested features:

• Visual/graphical representation of benchmark history over time
• Binary size, internal flash usage, and memory region tracking
• Results explicitly linked to commit hashes (currently linked to releases, not individual commits)
• A publicly accessible dashboard for historical trends

These would be enhancements beyond what is currently documented. I'd recommend opening or expanding the GitHub issue in the esp-bsp repository with these specific gaps, as the existing CI infrastructure could potentially be extended to support them — but I cannot confirm implementation details beyond what the knowledge sources describe.