Ping! Any specific insights for this benchmark?

Will profile today.

Scores on Nexus 7 2nd Gen - Maintain 50fps:
SW - 7.18
GPU - 60.6

It looks like there are two bottlenecks here: Main thread takes a while, and the actual raster task time takes a while. GPU thread has a fair amount of gaps and looks like it isn't the bottleneck.

As far as raster task time, we take around 5ms to draw ~50 images - about half the time is taken recording the commands to a picture, and half the time is taken playing back the picture via MultiPictureDraw. This seems a bit long for both steps, especially just recording a picture... not sure if this can be optimized.

Need to investigate main thread further. - attaching a trace.

Deleted: trace_svg_bouncing_png_images.json 12.0 MB

trace_svg_bouncing_png_images.json 12.0 MB View Download

On desktop (15" MBP 2013) we are GPU bound - it's interesting that we can only draw ~180 of the same image in a frame - there are probably opportunities to detect that the same image is being drawn multiple times and batch these into a single draw command?

Interestingly, on desktop, the "canvas bouncing png images" test, which produces a nearly identical effect, scores 5x better, so we're somehow generating much nicer GPU work.

looping in bsalomon in case he has some ideas on why this might be the case.

Not sure, but I'll try to grab a SKP tomorrow.

There's a fairly large overhead in ref churn during the draw image (dealing with the image decode controller). I'm working on a fix that should eliminate the churn by doing some of the ref up front for the duration of the raster.

vmpstr@, did you end up landing the CL mentioned in #7?

obsolete at this point.