Slider Knob out of the track

General discussion
1 
So i have this simple slider i have made but instead of having the knob outside the slider track i 
need it inside of it and i mannaged to make that but still possible to slide out of it

image

it should stop sliding here

image

Basic3DSlider[1] = lv_slider_create(BasicBoard);
lv_slider_set_mode(Basic3DSlider[1],LV_SLIDER_MODE_SYMMETRICAL);
lv_slider_set_range(Basic3DSlider[1], 10, 245);
lv_obj_set_size(Basic3DSlider[1], 350, 44);
lv_obj_set_style_outline_color(Basic3DSlider[1], lv_color_hex(0x484848), LV_PART_MAIN);
lv_obj_set_style_outline_width(Basic3DSlider[1], 1, LV_PART_MAIN);
lv_obj_set_style_bg_color(Basic3DSlider[1], lv_color_hex(0xCD3F3F), LV_PART_MAIN);
lv_obj_set_style_bg_color(Basic3DSlider[1], lv_color_hex(0x851D1D), LV_PART_INDICATOR );
lv_obj_set_style_bg_opa(Basic3DSlider[1], 255, LV_PART_MAIN);
lv_obj_set_style_bg_color(Basic3DSlider[1], lv_color_hex(0xFFFFFF), LV_PART_KNOB);
lv_obj_set_style_border_color(Basic3DSlider[1], lv_color_hex(0x851D1D), LV_PART_MAIN);
lv_obj_set_style_border_side(Basic3DSlider[1], LV_BORDER_SIDE_TOP, 0);
lv_obj_set_style_border_width(Basic3DSlider[1], 3, 0);
lv_obj_set_style_pad_all(Basic3DSlider[1], -4,LV_PART_KNOB);
lv_obj_add_event_cb(Basic3DSlider[1], ColorHandler, LV_EVENT_VALUE_CHANGED, NULL);
2

you can limit the movement of the slider. I believe the issue is already known.

If you need a slider range of 0 to 100 then you set the range to something like -10 to 110. attach a callback for the value changed event and if the value drops below 0 or goes above 100 you force it it back to either 0 or 100. what the actual min and max values are is going to depend on what you have the widget sized to. I do not remember off hand the factor I used based on the width of the widget. I would have to locate where I did it to get you that factor. If you mess with it a couple of times it’s not hard to dial in what the factor is.

1 Like
3

A feature to limit the knob movement was really came up several times.

I’ve just added it to our roadmap: docs(roadmap): add bar, slider, arc knob move inside feature · lvgl/lvgl@b4c3249 · GitHub

1 Like
4

I have discovered a temporary solution for my problem by modifying the archive. Specifically, I have implemented an offset in lv_slider.c by adding certain adjustments to it. This modification allows me to address my issue effectively for the time being.

from the line 230 to 238

int32_t real_max_value = slider->bar.max_value - 15;
int32_t real_min_value = slider->bar.min_value + 15;
/Figure out the min. and max. for this mode/
if(slider->value_to_set == &slider->bar.start_value) {
real_max_value = slider->bar.cur_value;
}
else {
real_min_value = slider->bar.start_value + 15;
}

image

Indeed, incorporating a feature that enables customization of the knob positions and behavior would be highly beneficial. Such functionality would allow users to tailor the settings according to their specific needs and preferences, enhancing the overall usability and flexibility of the system.

“Solves” using a bug

5

Now that you posted that graphic I see where the issue is. It’s in the knob offset. the “knob” is being rendered so the center of the knob is attached to where the value is on the indicator but the indicator when it is being drawn it not being drawn to align the center with the value but is is being drawn so the outside edge is aligned with the value. if you pad the knob on the right side by 15 to push it over that should fix the problem. it may however cause an issue at the other end of the slider.

so what has to happen is the padding needs to dynamically change as the slider is moving but the change is not going to be aligned in a manner that is even with the indicator. Te problem there is if you are say at a 50 on a 0 to 100 scale the knob would not be in the center of the slider like it should be.

This is actually a bug.

Look here.

image

The knobs position relative to the indicator changes as it moves. it’s not locked to the indicator at all… In order for this to work properly the knobs alignment to the value needs to move from left left side of the knob to the right side of the knob as the knob moves across the slider. the indicator also needs to do the same kind of a thing as well but it has to move from the right edge being attached to the value when the slider is at max and it needs to shift to the center as it is being slid to the left.

You can see it better here.

image
image1196Ă—624 34.9 KB

1 Like
6

Certainly, since the kisvegabor mentioned that there will be a feature addressing this issue in the future, it seems reasonable to utilize the “bug” as a temporary workaround until the feature is implemented. Considering that the slider in question is unique to this project and its purpose is simply to adjust the UI color, it doesn’t necessarily require extreme precision. As long as it serves its basic function of enabling color changes, it should suffice until the desired customization feature becomes available.

7

why are you not using lv_colorwheel for the color?

https://sim.lvgl.io/v9.0/micropython/ports/javascript/index.html?script_startup=https://raw.githubusercontent.com/lvgl/lvgl/b4c3249c2e1578227c22dd661fe2a77aacd4a5a2/examples/header.py&script=https://raw.githubusercontent.com/lvgl/lvgl/b4c3249c2e1578227c22dd661fe2a77aacd4a5a2/examples/widgets/colorwheel/lv_example_colorwheel_1.py

8

Color wheel uses a lot more CPU than the way i done using sliders

9

That’s more than likely because of the gradient that has to be processed.

10

Yes, considering the amount of usage, it becomes impractical due to the increased CPU utilization
makes my screen lag like 5 / 10 using a ESP32-S3 WROOM-S1 that has two cores

11

are you using DMA memory and double buffering? That will greatly improve speed. Also you do you your SPI speed turned up at all?

12

I am not sure but i think i am not using these also i dont have much experiene with ESP32 i dont really know what DMA memory is ;p
but about double buffering yes i am using it

13

if you are not using DMA memory then using double buffering is really going to be a waste of memory. DMA memory is memory that can be access without the processor needing to be involved. The benefit of this is when say transferring the data from the memory to the display the CPU is able to be off and doing something else, like filling the second buffer!!. This has a pretty decent boost in performance when the program doesn’t have to sit around and wait for the buffer to get emptied before it is able to do any more work. buffer sizes should be about 1/10th the total size of the display. so if you have a display that is 480 x 320 at 16 bit color then the buffer size should be uint8_t buf[(480 * 320 * 2) / 10]; This should be done for both buffers. When initializing the display buffers you want that to be done first thing as soon as your program starts. In order to get the buffer into DMA memory you need to use the SDK specific memory alloc functions with the proper flags set to instruct it to use DMA memory.

The reason why you want to do this first thing is so the memory doesn’t get used by something else. On the ESP32 there is not a large amount of DMA memory. with the ESP32-S3 there is more DMA memory available but that memory is located in SPIRAM which is quite a bit slower than SRAM so if you can get the buffers located in SRAM you will see the best performance gains for using DMA memory.

Make sense?

14

yes makes sense i will be using it for sure also could you take a look in this other post of mine?