Platform
Infineon PSoC Edge E84 EVK (Arm Cortex-M55), ModusToolbox 3.8, GCC, FreeRTOS, VG-Lite GPU.
Summary
In demos/music, pressing the NEXT track button makes the outgoing album cover flash/disappear instead of sliding smoothly. The PREV direction is unaffected. This is a regression vs. LVGL 9.2.
Root cause
music_width and music_height are declared uint32_t:
// demos/music/lv_demo_music_main.c
static uint32_t music_width = 0;
static uint32_t music_height = 0;
but track_load() uses them with a unary minus:
lv_anim_set_values(&a, 0, -music_width / 7); // landscape, NEXT
lv_anim_set_values(&a, 0, -music_width / 2); // portrait, NEXT
With unsigned operands, -800u / 7 evaluates to 0x24924932 (613566642). That value is then passed as end_value (int32) to the animation engine. The per-tick (step * end_value) >> LV_ANIM_RES_SHIFT in src/misc/lv_anim.c overflows int32, producing oscillating x values (±599k, ±1.2M, ±1.8M) instead of a smooth slide from 0 to ‑114.
Why only NEXT? Only the NEXT branch uses the unary minus; PREV uses positive music_width / N and works correctly.
Why not in 9.2? The same code in 9.2 used the LV_HOR_RES macro, which is signed. The regression was introduced when the demo was refactored to compute music_width/music_height at runtime via lv_obj_get_content_width() and store the result in unsigned statics, without updating the negation sites.
**Fix
--- a/demos/music/lv_demo_music.c
+++ b/demos/music/lv_demo_music.c
@@
-static uint32_t music_height;
+static int32_t music_height;
--- a/demos/music/lv_demo_music_main.c
+++ b/demos/music/lv_demo_music_main.c
@@
-static uint32_t music_width = 0;
-static uint32_t music_height = 0;
+static int32_t music_width = 0;
+static int32_t music_height = 0;