Path Rendering Performance

[Corey Lucier]

So I'm working on a next-gen design tool and Skia is performing wonderfully for us.  But we could always enjoy better performance.

We're currently leveraging a tiled renderer/compositor and sticking with cpu rasterization however (as it currently still beats the GPU flavor of Skia for complex content).  We can currently rasterize tiles no problem but wondering if there are any tricks we could use for SkPath instances specifically to speed things up.

1) Does leveraging SkPicture take any shortcuts or cache any path-specific data that might speed up successive rendering of the same path?

2) Is there a means of caching any SkPath internal intermediate data for use with successive render passes?

3) Rather than making a draw call twice on the same path data for a filled and stroked path, can one easily cache the results of the stroker so that at least the stroke path can be generated once and reused later?

4) Any other tricks to speed up path rendering?

Thanks,

Corey L.

[Jim Van Verth]

One cached optimization we have on the GPU is to use distance fields for certain paths -- the system will cache a signed distance field representation which can be re-rendered quickly, or rotated, or scaled/skewed within a certain range. It's currently limited to paths that have original bounds that are less than 64x64, and scaled bounds (i.e., after the matrix is applied) that are less than 256x256. It's designed for SVG icons on webpages. But within those constraints, if you create a path and reuse it, it should render quite quickly the second time.

Jim

--
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 post to this group, send email to skia-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Robert Phillips]

Is there some representative content you could share with us? I'm assuming a lot of large concave paths?

--

[Corey Lucier]

Not really but assume something equivalent to SVG tiger or around that level of complexity.

[Mike Reed]

Like nearly everything in paths, there are some speedups but not always in all circumstances.

Stroking

Distinguish between stroke-width 0 (hairline) and others. Hairlining (hairstroking) is a very different code-path than "thick" stroking. It is funny in that it doesn't zoom w/ the CTM, but it is bloody fast.

For thick strokes, speed tricks can depend on the complexity of the path and the backend (cpu -vs- gpu)

- If the path is really a rect or oval, please please call those draw methods instead, as they are very often faster (esp. on GPU)

- GPU : some paths are stroked analytically in the shader, but not all. Details from someone else...

- CPU : thick (non-rect) strokes are implemented by first generating a new path, and "filling" that one. This can be accelerated by the client doing this step themselves...

SkPaint paint;

paint.setStyle(SkPaint::kStroke_Style);

paint.setStrokeWidth(...);

// set other stroky things like caps, joins, patheffect

paint.getFillPath(original_path, &result_path, optional_cull_rect);

Now you can draw the "stroke" by filling result_path, which will save you the "getFillPath" step each time.

[Mike Reed]

At least early versions of the Tiger were only polygons (afaik). Does your data use curves (quads, cubics, conics) or just lines?

[Corey Lucier]

Here is one example that both Skia raster and GPU can pull off no problem.  But could stand to be a bit faster.

[Corey Lucier]

And here is one that really gives Skia GPU and CPU a run for it's money.

As mentioned earlier we're bound to using Skia software renderer for now given the perf of GPU for complex renditions.

This particular SVG is consistently hot at SkChopCubicAt() <---haircubic when interacting with some of the more complex sub-paths.

Maybe there's a way to cache this work somehow?

[Corey Lucier]

To clarify, anyone have thoughts on the SkChopCubicAt hotspot?  

[Cary Clark]

Use fewer cubics? If you're describing circles or arcs, conics will be more accurate. If your cubic is simple, it can often be represented by a quadratic.

On Thu, Apr 9, 2015 at 5:05 PM, Corey Lucier <corey....@gmail.com> wrote:

To clarify, anyone have thoughts on the SkChopCubicAt hotspot?  

--

[Cary Clark]

Also, SkChopCubicAt has recently been rewritten to use SIMD instructions if they are available, so there's not much more performance gain to be had, short of reducing the data set.

[Corey Lucier]

Thanks Cary, in this case this is just representative SVG from the wild being rendered (the map SVG attached above).

We're using the tip of Skia (master) so I'd assume we have the bleeding edge.

I was just hoping that there was some way to cache the rasterization/edge-building results (or whatever SkChopCubicAt produces) for successive render passes.

[Philip Rogers]

Are you using the SVG implementation in Skia or your own?

--

[Corey Lucier]

Our own, it's not really SVG, just analogous.