Shadow_width to shadow_blur_radius

Feature request
1

currently shadows use a property called shadow_width however css uses blur_radius
there is not only a difference in name but also in content.
from my limited testing:

shadow_width is approx (2*blur_radius)+1.
i.e.
(shadow_width-1)/2 approx blur_radius.

I am not sure what the reason for this difference in api is but it leads to unneccesary conversion efforts when given css definitions by a UI graphics designer.

I suggest renaming shadow_width to blur_radius or shadow_blur_radius and aligning values with css.
pro: better workflow, no conversions
con: we lose some resolution in the setting (which css didnt have to begin with tho)

2

Not need sincerely, you have already:

lv_obj_set_style_local_shadow_opa(Label2, LV_BTN_PART_MAIN, LV_STATE_DEFAULT, 100);
  lv_obj_set_style_local_shadow_width(Label2, LV_BTN_PART_MAIN, LV_STATE_DEFAULT, 5);
  lv_obj_set_style_local_shadow_spread(Label2, LV_BTN_PART_MAIN, LV_STATE_DEFAULT, 1);
  lv_obj_set_style_local_shadow_ofs_x(Label2, LV_BTN_PART_MAIN, LV_STATE_DEFAULT, 4);
  lv_obj_set_style_local_shadow_ofs_y(Label2, LV_BTN_PART_MAIN, LV_STATE_DEFAULT, 4);

with transparency and shadow_spread you can made all you want

3

I am aware “you can make all you want”
but shadow_spread and shadow_opacity have specific analogs in CSS that work the same as LVGL as far as i’m aware,
the analog of shadow_width in css is blur_radius though, so if you claim to implement CSS i dont understand why not to use the actual CSS definition.
This would lead to very minor code changes in lv_draw_sw_rect.c so i think this is worth changing to be more in line with CSS.
As this is a minor change and i could make a pull request for it if that would help.

4

would still like to get a comment on this since it it doesnt conform to the CSS definition of shadows.
see: https://www.css3.info/preview/box-shadow/
a workaround is not a good permanent solution

5

@kisvegabor There is a good point raised here.

6

True, shadow_width is rather like blur_diameter which is really inconsistent with CSS’s blur-radius way of thinking.

I think the best would be to

  1. rename it to shadow_blur_radius
  2. really calculate with it as a radius an not a diameter.

Unfortunately, both are breaking changes. So we can

  1. wait until v9
  2. or make this breaking change in v8.x
  3. or add functions for backward compatibility. E.g.
void lv_obj_set_style_local_shadow_width(lv_obj_t * obj, lv_coord_t w, lv_style_selector_t selector) 
{
  lv_obj_set_style_local_shadow_blur_radius(obj, w/2, selector);
}
7

I like option 1. and 2. and can live with both.
3. only if the function disappears in 9.0 as otherwise the api gets cluttered imho

also note/keep in mind the part that in lvgl it is not just *2, but also offset with 1 in shadow_width, is a 0 in blur_radius.

8

Sure, shadow_width would be marked as deprecated.

Yes, e.g. shadow_width=3 means blur_radius=0.5 which won’t be supported. I think it’s an acceptable regression.

1 Like