feat: Add ThorVG build option (IEC-155)

[espressif2022]

Checklist

• Component contains License
• Component contains README.md
• Component contains idf_component.yml file with url field defined
• Component was added to upload job
• Component was added to build job
• Optional: Component contains unit tests
• CI passing

Change description

1: Add Loaders Support option:['tvg', 'svg', 'png', 'jpg', 'lottie']
2: Add log_enable/thread_enable flag

[suda-morris]

previously, we've enabled this feature by default

[espressif2022]

yeah，lottie, svg, tvg is enabled by default. I'll enable it.
And if we enable the thread flag, some lottie file will crash, I can't find the reason now, so I set it disable by default.

[igrr]

If enabling thread flag doesn't work (i.e. it results in a crash), why do we want to keep this as an option? Wouldn't it be better to disable this option, and re-enable it when the bug is fixed?

[igrr]

@espressif2022 Now that you don't get a crash when using threads, can we change this to default y?

[espressif2022]

@espressif2022 Now that you don't get a crash when using threads, can we change this to default y?

Done.

[igrr]

@espressif2022 I have had to change thorvg CMakeLists a lot in this commit: 83ac6d6, it has resolved the PIC issue, details are in the description.

Could you please rebase your changes upon the new version? Sorry for the trouble.

For pthread support, could you please try it again? Since PIC is now properly disabled, I guess it shouldn't crash anymore.

[espressif2022]

@espressif2022 I have had to change thorvg CMakeLists a lot in this commit: 83ac6d6, it has resolved the PIC issue, details are in the description.

Could you please rebase your changes upon the new version? Sorry for the trouble.

For pthread support, could you please try it again? Since PIC is now properly disabled, I guess it shouldn't crash anymore.

Thank you very much, I will deal with it ASAP.

[espressif2022]

@espressif2022 I have had to change thorvg CMakeLists a lot in this commit: 83ac6d6, it has resolved the PIC issue, details are in the description.

Could you please rebase your changes upon the new version? Sorry for the trouble.

For pthread support, could you please try it again? Since PIC is now properly disabled, I guess it shouldn't crash anymore.

I've test it. the flags of thread and PIC are ok on v0.13.8.

[igrr]

Generally if you don't have more to say in the help text than in the option name, you don't need to add help text... Repeating the same thing twice doesn't really explain anything better.

[espressif2022]

Good suggestion, thanks.

[igrr]

We also get a build failure now:

../../../../../thorvg/thorvg/src/renderer/sw_engine/tvgSwRasterTexmap.h: In function 'void _rasterBlendingPolygonImageSegment(SwSurface*, const SwImage*, const SwBBox*, int, int, AASpans*, uint8_t)':
../../../../../thorvg/thorvg/src/renderer/sw_engine/tvgSwRasterTexmap.h:433:1: error: insn does not satisfy its constraints:
  433 | }
      | ^
(insn 1155 1121 949 56 (set (reg:SF 21 f2 [612])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC14") [flags 0x2]) [0  S4 A32])) 49 {movsf_internal}
     (nil))
during RTL pass: postreload
../../../../../thorvg/thorvg/src/renderer/sw_engine/tvgSwRasterTexmap.h:433:1: internal compiler error: in extract_constrain_insn, at recog.c:2671
0x13cebd6 internal_error(char const*, ...)
	???:0
0x5ef48f fancy_abort(char const*, int, char const*)
	???:0
0x5c52dd _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
	???:0
0x5c5303 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
	???:0
0xbecba7 extract_constrain_insn(rtx_insn*)
	???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

I guess it's the same as jcmvbkbc/gcc-xtensa#14. Please try adding -fno-if-conversion to ThorVG compilation flags (jcmvbkbc/gcc-xtensa#14 (comment)).