ThorVG inclusion and related fixes causes deviation from ThorVG

[J-u-n-o]

LVGL version

v9

Platform

Noticed deviation from the ThorVG library on the master merge (commit) related to
#7772

I noticed LVGL commits into the copied ThorVG sources.
Now ThorVG is still not at 1.0.
This will/can be hard to merge ThorVG fixes/feature in the future.
Especially because also the ThorVG folder structure is flattened; hard to perform a diff to the ThorVG clone.

Also the devs of ThorVG do not benefit from these commits.

My suggestion is:

• To keep the ThorVG structure and adapt the LVGL make/build files to include the sources; set the include path to internal or external in the build, and to make the linker use the sources or external ThorVG library.
• Add (new) ThorVG for the memory macros. This can be a renamed copies of the LVGL functions. Also the ThorVG macros should be defined to the LVGL functions so both libs are using the same memory pool.

Note:
I added (locally) 16bit support to the ThorVG files. I still need to cleanup this: I replaced the 32bit support ;-). The usage of templates for uint32/uint26/uint8 should fix this.
Background: Now both 32 and 8 bit are supported using if-else using the type.
But I did this in the latest ThorVG 0.15 release and kept their folder structure. So they also would benefit.

I also have some (minimal) SVG animation working using SVG as a control/widget, simular as the Lottie control/widget. It parsed the SVG once and reusing the tree (simular like Lottie).

What happened?

looking at the master changes not merged to my local branch

How to reproduce?

No response

[kisvegabor]

As LVGL is build system neutral so it should work with any simple file globbing builders (Arduino, Eclipse, etc). As ThorVG sets include paths to include headers directly (without ../ or folders) we can either

1. make the directory structure flat
2. change all the include paths.

Otherwise we need to set include paths somewhere which is not always possible (e.g. in Arduino)

Regarding memory allocations: when we will update to ThorVG v1.0 we can use the their allocator templates as described here.

Regarding the RGB565 support: It's awesome! I think it should go to the upstream ThorVG to allow using this with external ThorVG and to lower the deviation from the upstream.

Regarding SVG animations: It's really interesting. Have you seen this PR?

[J-u-n-o]

Thanx for the reply and the good work!

I used the arduino build system, but LVGL also has sub folders, but indeed requires extending the include paths.
Take a look at (Adding include paths for library compilation) #502.
Maybe make a script changing the includes in the ThorVG files so they will contain a path; this automates the process of adding manual changes...

Looked at PR#7141.
I took the Lottie approach: create a (new defined) lv_svg struct, which contains (like Lottie):
`

lv_canvas_t canvas; /* inheritance parent */
lv_svg_node_t * doc;
lv_vector_dsc_t* dsc;
lv_svg_render_obj_t * list;
Tvg_Canvas * tvg_canvas;
lv_anim_t * anim;
float animTime_ms;
int32_t last_rendered_time;

`
And play the animation using the (Lottie like) draw/update (event) callback.

I need to make a clone and have the code reviewed before committing this to the clone.
But first have my prototype to function...

[J-u-n-o]

Just got an spark.

My two cents:
Make a thorvg fork in lvgl, and on a branch make the required (lvgl) changes.
And make this lvgl/thorvg repo a sub repo of lvgl.
This would make it more clear what commit of thorvg is used, and what lvgl changes are made using git viewers.
Updating the thorvg code is now (just) a pull/merge, and running a script to make the lvgl changes.

[lvgl-bot]

We need some feedback on this issue.

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

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

[lvgl-bot]

As there was no activity here for a while we close this issue. But don't worry, the conversation is still here and you can get back to it at any time.

Feel free to comment if you have remarks or ideas on this topic.