SkPicture Optimization?

[Corey Lucier]

Is there a mode of SkPicture recording, or post processing capability, of SkPicture such that any redundant ops are culled out?

For instance we have a super large DOM and much of my records ops consist of canvas save()  push matrix, then restore() calls one after the other with nothing actually done between them...  (obvious artifact of us keeping the total matrix up to date as we walk down our scene graph)... 

-C

[Mike Klein]

Yes, you can pass an SkRTreeFactory as the second argument to SkPictureRecorder::beginRecording().  This skips any operations that don't affect any pixels in the destination canvas clip, which means all spans of operations that draw nothing will be skipped.

--
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 https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Corey Lucier]

This is great. Does it add recording overhead ? 

I have a case where I want to essentially playback my DOM(tree) walk, rendering at high res and a lower res version as well.  So figured since you can't record and render in the same pass, I'd record the most optimal SkPicture I could, then play back twice (avoiding the tree walk and the extra computations we do during the walk for culling, etc.).

I'm relatively new to SkPicture...is anything actually being rendered when recording or is most everything short-circuited and pretty much a noop?

-C

[Jeremy Roman]

Unless you go out of your way to raster in advance, it should defer that until the picture is drawn to a raster surface. This is how exactly how Blink works (and deals with device scale factor, etc.).

[Mike Klein]

Yes, an R-Tree adds some cost to recording, but not much.  I'd recommend you default to using an R-Tree with SkPictures, perhaps only going with the default no-R-Tree mode when you know the content is very short or will be certainly played back with no clip.

No pixels are touched (or even exist) when recording an SkPicture.  We're pretty much just scribbling down the calls you make to SkCanvas so that we can re-create them later.

I think your proposed use case sounds like a good fit.

--

[Corey Lucier]

Final question. Will help me crystallize my understanding of SkPicture.

After recording an SkPicture, is it feasible to:

A. Render/play-back that picture at a new scale (and benefit from the culling etc. that occurs when rendering something super small for instance) - 

B. Render that picture with a new clip (say if I wanted to render that same picture across multiple tiles) - would it take my global clip into account as well as any backed into the picture?

Thanks,

C

[Mike Klein]

Yep, yep.  When you're done recording a picture, you've got an SkPicture*, right?  Any you're drawing it into some destination SkCanvas*?

Just do the scale / clip things you want to your destination canvas, then call SkCanvas::drawPicture().

[Mike Klein]

If it helps to think of it this way, drawPicture() is just a drawRect() with a fancy shader.