SkiaViewer and SVG rendering

[render dender]

Hey guys.

I've been experimenting with Skia Viewer on Android and I'm especially interested in rendering of SVGs and some extreme use-cases with a lot of redrawing.

So, let's say I want to render an SVG with transform(just scaling). What's the optimal way to do that? Currently I'm just setting:

   canvas->scale(. . .);

right before:

   slides[currentSlide]->draw(canvas);

With redrawing of every frame it's REALLY slow even on small SVGs. Am I doing something wrong or that's pretty much expected? Maybe I could add transform somewhere to SVG directly instead or it doesn't matter in terms of the pipeline?

Would be glad to hear any suggestions.

[Asger Jørgensen (Asger-P)]

Hi Pavlo

I would like to know the same, but here is a hack until a better solution.

Change the width and the height in the SVG file, it is after all just xml. 

Near the top , in the <svg tag there are width and height attribute that determine how

big the svg is drawn, but have in mind, that you MUST keep the aspect ratio, if not the 

position might not be right.

You can use a browser for testing

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg
   width="600.18507px"
   height="900.00097px" 

Best regards
Asger

[render dender]

Hi Asger!

Yeah, I could change SVG like that. But that would introduce some overhead on parsing the .svg again then. The scale is just for the sake of example and I want to generalize later to any transform.

For example, if I wanted to rotate the .svg every frame, where would I need to apply transform optimally? To the canvas like I'm currently doing or maybe to the SVG data structure itself that you get after parsing of .svg?

I imagine the transform applied to canvas is placed into stack and is kind of an "abstraction layer" above anything rendered under it, be it svg or not svg. And I thought maybe, I could apply transform to SVG data structure directly, to apply transform to the root of the SVG scene-graph or something and maybe that would be more efficient in terms of the pipeline, but again I'm not sure how SVGs are rendered in Skia exactly, maybe there's no difference.

___

Thanks

[Brian Osman]

You're right that it shouldn't make any difference - applying the transform to the canvas should be at least as fast as any other technique. Questions:

1) How slow are we talking about here?

2) What device is this on?

3) How complex is your SVG?

4) You're measuring this with a release (not debug) build, right?

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/b329d91c-02e8-4e74-8fbc-3913e970b091n%40googlegroups.com.

[Brian Osman]

...

Forgot one more:

5) Is this with the GPU backend? Or are you use the CPU?

[render dender]

Hi, Brian!

I'm trying to basically figure out how fast Skia can render SVGs on dynamic cases and make sure it's done optimally and there's no mistakes on my part.

1/3) About 12fps on ghostscript tiger for reference.

2) High-end device with snapdragon 888.

4) Yes, Release build.

5) Yes, Vulkan backend.

пятница, 10 февраля 2023 г. в 16:57:28 UTC+3, brian...@google.com:

[Michael Ludwig]

Thank you for the answers to those questions. We use a version of the ghostscript tiger in some of our internal performance tests. The snapdragon 888 appears to have an Adreno 660 GPU, which do not currently test. Our closest match is the Adreno 640, which is able to draw the tiger in about 3.7ms if using an MSAA4 surface with our Vulkan backend, or about 6ms if not drawing directly to a multisampled surface.  Even at 6ms, that corresponds to about 165fps so 12fps is pretty different from what we are measuring.

One possibility is the source of the tiger could be different, and I believe we rely on chromium's SVG processing to convert the SVG into skia commands (that we then serialize and preserve for reproducible performance benchmarking). The SVG module that's in Skia is distinctly different from how chromium handles SVG. It's possible that either its implementation makes different decisions compared to chromium's, which leads to less optimal drawing operations, or that its overhead of converting its SVG description into SkCanvas draw calls is not well optimized. Or there is something off about your build where you aren't getting correct SIMD support or are accidentally compiling a debug build somehow.

[render dender]

Thanks, Michael!

Your answer really helped me with further investigation. Turns out there were some problems with the Skia build, now the performance is pretty close to yours I think.

___

Cheers,

Denis

четверг, 16 февраля 2023 г. в 23:53:47 UTC+3, michae...@google.com: