Skip to content

fix(slider): allow knob update while dragging even if scroll object is active#9906

Open
dmd79 wants to merge 1 commit intolvgl:masterfrom
dmd79:fix/slider-update-knob-pos-during-drag
Open

fix(slider): allow knob update while dragging even if scroll object is active#9906
dmd79 wants to merge 1 commit intolvgl:masterfrom
dmd79:fix/slider-update-knob-pos-during-drag

Conversation

@dmd79
Copy link
Copy Markdown

@dmd79 dmd79 commented Mar 24, 2026

Problem

When dragging a horizontal slider, lv_indev_get_scroll_obj() may
return non-NULL causing update_knob_pos() to return early without
sending LV_EVENT_VALUE_CHANGED. This prevents the slider from
updating continuously during drag as documented.

Root cause

In update_knob_pos(), the check:

if(lv_indev_get_scroll_obj(indev) != NULL)
    return;

exits the function even when the slider is already in dragging mode.

Fix

Skip the scroll object check when the slider is already dragging:

if(lv_indev_get_scroll_obj(indev) != NULL && !slider->dragging)
    return;

Tested

Verified on ESP32-S3 with touchscreen display running ESPHome.

…s active

When a horizontal slider is being dragged, lv_indev_get_scroll_obj()
may return non-NULL causing update_knob_pos() to return early without
sending LV_EVENT_VALUE_CHANGED. Skip this check when the slider is
already in dragging mode so the knob position updates continuously
during drag as documented.
Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 1 file


Since this is your first cubic review, here's how it works:

  • cubic automatically reviews your code and comments on bugs and improvements
  • Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
  • Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
  • Ask questions if you need clarification on any suggestion

@github-actions
Copy link
Copy Markdown
Contributor

Hi 👋, thank you for your PR!

We've run benchmarks in an emulated environment. Here are the results:

ARM Emulated 32b - lv_conf_perf32b

Scene Name Avg CPU (%) Avg FPS Avg Time (ms) Render Time (ms) Flush Time (ms)
All scenes avg. 29 37 7 7 0
Detailed Results Per Scene
Scene Name Avg CPU (%) Avg FPS Avg Time (ms) Render Time (ms) Flush Time (ms)
Empty screen 11 33 0 0 0
Moving wallpaper 2 33 1 1 0
Single rectangle 0 50 0 0 0
Multiple rectangles 0 33 0 0 0
Multiple RGB images 0 39 0 0 0
Multiple ARGB images 11 39 3 3 0
Rotated ARGB images 55 (+1) 44 15 15 0
Multiple labels 7 35 0 0 0
Screen sized text 97 47 20 20 0
Multiple arcs 33 33 7 7 0
Containers 4 (+4) 37 0 0 0
Containers with overlay 98 21 44 44 0
Containers with opa 18 38 1 1 0
Containers with opa_layer 18 (-1) 33 (-1) 6 6 0
Containers with scrolling 44 45 12 12 0
Widgets demo 71 (-1) 40 (+1) 17 (+1) 17 (+1) 0
All scenes avg. 29 37 7 7 0

ARM Emulated 64b - lv_conf_perf64b

Scene Name Avg CPU (%) Avg FPS Avg Time (ms) Render Time (ms) Flush Time (ms)
All scenes avg. 24 37 6 6 0
Detailed Results Per Scene
Scene Name Avg CPU (%) Avg FPS Avg Time (ms) Render Time (ms) Flush Time (ms)
Empty screen 11 33 0 0 0
Moving wallpaper 1 33 0 0 0
Single rectangle 0 50 0 0 0
Multiple rectangles 0 35 0 0 0
Multiple RGB images 0 39 0 0 0
Multiple ARGB images 11 42 0 0 0
Rotated ARGB images 29 33 9 9 0
Multiple labels 2 35 0 0 0
Screen sized text 84 46 18 18 0
Multiple arcs 31 33 6 6 0
Containers 4 37 0 0 0
Containers with overlay 89 22 41 41 0
Containers with opa 14 38 1 1 0
Containers with opa_layer 6 36 1 1 0
Containers with scrolling 47 48 12 12 0
Widgets demo 68 40 15 15 0
All scenes avg. 24 37 6 6 0

Disclaimer: These benchmarks were run in an emulated environment using QEMU with instruction counting mode.
The timing values represent relative performance metrics within this specific virtualized setup and should
not be interpreted as absolute real-world performance measurements. Values are deterministic and useful for
comparing different LVGL features and configurations, but may not correlate directly with performance on
physical hardware. The measurements are intended for comparative analysis only.


🤖 This comment was automatically generated by a bot.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes slider drag behavior so knob/value updates continue while dragging even when the active input device reports a non-NULL scroll object, matching the documented “continuous update during drag” expectation.

Changes:

  • Update update_knob_pos() to ignore lv_indev_get_scroll_obj() when the slider is already in dragging mode.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +562 to 563
if(lv_indev_get_scroll_obj(indev) != NULL && !slider->dragging)
return;
Copy link

Copilot AI Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change alters behavior when indev->pointer.scroll_obj is non-NULL during an active drag, but there’s no automated coverage for this regression scenario. Consider adding a unit test in tests/src/test_cases/widgets/test_slider.c that starts a pointer drag, then (e.g. via an LV_EVENT_PRESSING | LV_EVENT_PREPROCESS callback) forces lv_indev_active()->pointer.scroll_obj non-NULL while slider->dragging is true, and asserts that the slider value continues updating / LV_EVENT_VALUE_CHANGED still fires.

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants