Wiesław ŠoltésWorking on Svg animation support for my Svg.Skia library https://github.com/wieslawsoltes/Svg.Skia
Svg control also supports pointer evens and hit testing, this paired with animation system opens up new possibilities.
Jan Dytrych🇨🇿🇺🇦@soltes SVG UI with JavaScript? I do utilize SVG hit testing in @skipperapp so folks can click on SVG button and run some action. It's fun and works. Only issue is loading on RaspberryPi, it's slow like 3 seconds and then 900ms to update.
@jan @skipperapp did d you try printing profiling to see where the hot path is on pi ? That would help me optimizing
@soltes @skipperapp well, the issue is in loading SvgDocument and then running transform to render objects, that was slow in Rpi, render itself is quite fast. As far as I can remember. I don't have any profiler on Rpi, but can setup sample if you let me know how 😃
@jan @skipperapp well ideally it would be dotTrace profiling result 😅
@jan @skipperapp anyway will try to optimize the loading and transformation part 💪
@soltes @skipperapp maybe ultra from @xoofx might work on Raspberry PI? https://github.com/xoofx/ultra
@soltes @skipperapp the SVG I was testing is this one: https://bin.dytrych.cloud/download/b3b841335df2e348/#m-yRcuucR2wJ3m5ejiB6Yw
Will try today/tomorrow on CM5 in release mode and add few timers.
First, I load the SVG
SvgImage.Source = svgString;
_document = ((Svg.Model.Drawables.Elements.FragmentDrawable)SvgImage.SkSvg.Drawable).Element as SvgDocument;
- that takes about 3 seconds (+/-)
- then I do alter SvgDocument and force repaint, that took about 900 ms (+/-).
@soltes @skipperapp found VECTOR_IMAGE_MEASURE_PERFORMANCE enabled by default. Can test it with latest version on console...
@jan @skipperapp I don't think its best way to load SvgDocument, I would load SvgDocument using its api and the use SKSvg to process it after alteration.
@soltes @skipperapp well this is only initial. I do load SVG and then alter SvgDocument DOM and update rendering objects.
On my #uConsole with CM5 it runs great!
INFO Page Solar charging appeared.
DEBUG Vector image render render at 129 ms
DEBUG Vector image render end at 129 ms
DEBUG Vector image render Instructions exec at 0 ms
DEBUG Vector image render Instructions update styles at 0 ms
DEBUG Vector image render end at 0 ms
Interesting, have CM4 around, will test it too!
@soltes @skipperapp yes, CM4 in DRM is slow. Will investigate further.
@soltes @skipperapp Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render render at 4260 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render end at 4260 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render Instructions exec at 0 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render Instructions update styles at 0 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render end at 0 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render end at 4260 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render Instructions exec at 0 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render Instructions update styles at 0 ms
Apr 03 22:24:22 skipper SkipperApp[612]: DEBUG Vector image render end at 0 ms
@jan @skipperapp seems like hardware is slow?
@soltes @skipperapp the CM5 is 2x-3x faster than CM4 so the numbers doesn't match - CM5 is running Wayland 1280x768 resolution and CM4 is running in DRM mode with Full HD, will try CM5 in DRM mode in Full HD, if that makes a difference. But tomorrow! 😉 Thank you!
@jan @skipperapp it would be helpful to at least get split timing for loading documenting, creating document model (SKPicture) and the rendering time from picture model to png, it would tell me a lot :)
@jan @skipperapp I see in the sample svg 19 paths with opacity, this might cause some issues as opacity might require creating layer which is very expensive and might be issue on low powered devices, maybe in those case we could optimize