It's painting per zoom change, whereas it used to zoom as a bitmap (if it was a 3d transform). Obviously a pixelated view isn't ideal either, but it was silky smooth.

I've tried 3d & 2d transforms, same issue. Is it painting the content too big? As in, painting all the stuff out of the overflow.

This technically regressed in https://chromium.googlesource.com/chromium/src/+/66978ff65abbb473f8662444c2dc0823e0f45795 but that was just fixing a bug that previously had us drawing a low resolution.

I've attached a minimized repro. There's a blurry blue rect in the center. The further you scroll (even past when the blur fills the screen), the more janky things get.

The main cost here is in computing a really massive software blur filter. Printing the filter bounds in SkBlurImageFilter.cpp, it looks like we aren't clamping to tile boundaries and are unnecessarily filtering content outside the tile bounds.

Deleted: tile2.html 1.7 KB

tile2.html 1.7 KB View Download

In order to compute the edge bounds correctly, we do need to grow the intermediate buffers larger than the tile boundaries. The more blur, the more overlap there is between tiles. This is an unfortunate consequence of the switch to impl-side painting: we do a lot of redundant computation which we didn't do when we draw the content as a single canvas. We might be able to gain this back with atlasing; robertphillips@ would know better than I.

Note that things are much better with Ganesh (--enable-gpu-rasterization), because for large blurs, we downsample, then blur, then upsample. We could consider doing that on CPU as well.

Chris and I talked offline and I'd like to switch this bug to be just fixing the CPU filter performance issue that  https://crbug.com/600482  exposed.

How difficult would the CPU filter optimization be?