Blending/fading of body shadow

[jupeos]

I’m attempting to use a couple of base objects to provide drop shadows to a button. I’m testing using the simulator so hw independent at this point.

The intent is to duplicate the rendering provided by a graphics designer without using an image button, i.e. natively draw it. The 2 base objects/widgets provide a drop shadow of different weights & positions in order to give depth to the button face.

The issue I’m running into is that the opacity of a drop shadow cuts off early due to the value of LV_OPA_MIN being set to 16 (lv_color.h). This makes for an ugly approximation.
If I modify LV_OPA_MIN to a smaller value e.g. 2, I get the expected blending/fading.

A few related questions:

1. I’m sure there was a good reason to set LV_OPA_MIN to 16, so what am I screwing up by reducing it, e.g. CPU cycles, effect on existing, pre-canned widgets etc.?
2. Is there a better way to create a fading outline shadow? The only way I could think off was to use a radial gradient which currently is not supported by LVGL.
3. For a small number of widgets (<30) per screen is there a notable performance difference in using raw graphics (image buttons) vs native drawing? (I realise I haven’t spec’d hw but a general idea would be good). It’s much simpler to import graphics to image buttons than building them from scratch (RAM expense aside).

For privacy concerns, I am unable to upload the actual graphics but an equivalent object represents the issue. (Ignore the green/black gradient, I’m focused on the delineation of the shadow boundary).
This is what I would like:

And this is what occurs by default

[embeddedt]

@jupeos

I’m sure there was a good reason to set LV_OPA_MIN to 16, so what am I screwing up by reducing it, e.g. CPU cycles, effect on existing, pre-canned widgets etc.?

@kisvegabor would have to answer this, but I’m suspicious it was set that way with the assumption that people are only going to be using small shadows. With a small shadow, the last few pixels of the gradient could not be drawn and the difference probably wouldn’t be visible.

Keep in mind that large shadows with opacity like this can quickly slow down the render speed.

[jupeos]

The large shadow was only intended to highlight the issue. I am actually using much smaller shadows (half this) but the delineation is visually apparent.

[kisvegabor]

In v7 LV_OPA_MIN was already updated to 5 but I’ve further reduced to 2 - as you suggested.

@jupeos

I’m sure there was a good reason to set LV_OPA_MIN to 16, so what am I screwing up by reducing it, e.g. CPU cycles, effect on existing, pre-canned widgets etc.?

I’ve introduced LV_OPA_MIN/MAX to save expensive calculations for almost transparent/cover areas. To handle rounding errors, a smaller value should be enough too.

@jupeos

Is there a better way to create a fading outline shadow? The only way I could think off was to use a radial gradient which currently is not supported by LVGL.

Shadows are the best way I could imagine for this purpose.

@jupeos

For a small number of widgets (<30) per screen is there a notable performance difference in using raw graphics (image buttons) vs native drawing? (I realise I haven’t spec’d hw but a general idea would be good). It’s much simpler to import graphics to image buttons than building them from scratch (RAM expense aside).

Both (raw images and native drawing) have pros and cons. Native drawing
+ is more flexible, you can edit or animate colors and sizes freely.
+ needs no flash
- slower, shadow drawing is especially performance-hungry
- is limited to the capabilities of LVGL. E.g. you can’t draw a radial gradient now.