Add SVG support about lvgl HOT 8 OPEN

My idea was to return an lv_image_dsc_t or lv_draw_buf_t.

Yes. I agree. I mean the lv_image_dsc_t->data field should have a type of lv_vector_dsc_t, we need a way to describe loaded vector image.

I found that in many project it would be quite useful to just preload some images e.g. from an SD card, or convert all SVG on startup according to the display size.

We have done similar thing by call lv_image_decoder_open() early before apps starts, put them to cache. Maybe a cache attribute of persist would be even better.

from lvgl.

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

from lvgl.

Not stale, I'll work on it when the Lottie update is merge.

from lvgl.

It can be just a simple function like lv_image_preload(img_src, buf, ...);

I imagined this function will return a const struct lv_vector_dsc_t, and this is why #5970 is opened.

There are other cases may need consideration. For example how to add a normal image rotation to const lv_vector_dsc_t. It's great you can work on it. 👍

from lvgl.

My idea was to return an lv_image_dsc_t or lv_draw_buf_t. It's basically just an image saved in a memory managed by you (and not the cache). So it applies to PNG, JPG, etc too.

I found that in many project it would be quite useful to just preload some images e.g. from an SD card, or convert all SVG on startup according to the display size.

from lvgl.

Yes. I agree. I mean the lv_image_dsc_t->data field should have a type of lv_vector_dsc_t, we need a way to describe loaded vector image.

I was thinking only in rasterized images. However, if we had a description for vector data using lv_vector_dsc_t as an image, it would be a convenient way for the user to draw any vector graphics by hand too.

We have done similar thing by call lv_image_decoder_open() early before apps starts, put them to cache. Maybe a cache attribute of persist would be even better.

My only concern is that this way the user has less control over the memory usage. With lv_image_preload(img_src, buf, ...); as buf any memory address can used e.g. in external RAM.

from lvgl.

My only concern is that this way the user has less control over the memory usage. With lv_image_preload(img_src, buf, ...); as buf any memory address can used e.g. in external RAM.

That can be done by

static lv_draw_buf_t ext_ram_draw_buf;
lv_image_decoder_open(&decoder_dsc, src, &args);

// lv_image_dsc_t* I_manage_the_memory_draw_buf = (void*)lv_draw_buf_dup(decoded);

lv_draw_buf_copy(&ext_ram_draw_buf, NULL, decoded, NULL);

lv_image_decoder_close(&decoder_dsc);
// lv_image_cache_drop(src);

from lvgl.

In lv_image_decoder_open(&decoder_dsc, src, &args); there were a malloc temporarily. What if in args we optionally pass a buffer?

from lvgl.