Fast GPU accelerated rounded rectangle drop shadows

[Evan Wallace]

Skia currently special-cases rectangle shadows for speed (https://codereview.chromium.org/119343003/) but does not special-case rounded rectangle shadows as far as I can tell. I just came up with a similar technique that also applies to rounded rectangles: http://madebyevan.com/shaders/fast-rounded-rectangle-shadows/. Would a special case like this be a useful addition to Skia? I figured it's relevant given the prevalence of rounded rectangles on the web.

[Brian Salomon]

+Greg Humphreys

Yes, It is definitely of interest to us! Thanks for sharing this. I believe Greg added a special case for the GPU backend for some rounded rectangles that uses a look up table. IIRC it requires circular corners where the twice the blur radius plus corner radius is less than the rectangle width height.

Brian

On Mon, Mar 9, 2015 at 1:15 PM Evan Wallace <evan...@gmail.com> wrote:

Skia currently special-cases rectangle shadows for speed (https://codereview.chromium.org/119343003/) but does not special-case rounded rectangle shadows as far as I can tell. I just came up with a similar technique that also applies to rounded rectangles: http://madebyevan.com/shaders/fast-rounded-rectangle-shadows/. Would a special case like this be a useful addition to Skia? I figured it's relevant given the prevalence of rounded rectangles on the web.

--
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+unsubscribe@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.

[Greg Humphreys]

Correct, we special case the instances where the blur kernel is small enough that we can "ninepatch" the blurred rectangle, but when the blur is too large, this doesn't work either.

The reason we don't use an approximation approach is because we don't want to incur any visual popping should the rendering switch from GPU to CPU.  While it's not an explicit goal to make the eventual renderings pixel-exact (an impossible goal with shifting precisions on GPUs), we are striving for perceptual equality, and we didn't feel that any approximations we had come up with (we tried several!) achieved this goal.  To test, we just had a static rounded rectangle that was blurred with whatever approximation we were trying, and we would quickly flip back and forth between the analytic CPU solution and the GPU approximation.  We never found one that didn't have a "pop".

That being said, we are absolutely open to trying new ones; if this one has that property I think we should look into incorporating it.  Blur performance is still an issue for a few websites, despite the enormous improvements that Skia has made in the last two years.

Incidentally, your web page isn't quite accurate when it says that we compute shadows on the CPU and upload them; Skia computes shadows for rectangles directly per-pixel on the GPU an extremely efficient algorithm; each pixel is something like two texture lookups and a multiply.  We even do something very efficient in the case where the blur kernel is wider than half of one of the rectangle's dimensions, by discretely computing a definite integral of a piecewise cubic approximation of the gaussian (again, all on the GPU).

Greg Humphreys | Software Engineer [skia, chrome] | hum...@google.com | 434-260-0543