Poor Canvas::drawPath performance with anti-aliasing

[Christian Duerr]

I recently had the need to create a simple line to show a route in a navigation app and decided the best option for this would just be an SkPath with a stroke. However when profiling the performance of my initial implementation, I noticed that the call to `drawPath` was taking over 10ms, while drawing "only" 100 path stops or less (each step is just a line_to). After tweaking a bunch of stuff, I realized that setting anti-aliasing to `false` on my paint caused `drawPath` time to go down from over 10ms, to under 0.5ms.

Now this is a pretty small sample size of one very slow device (Mali T-860, using GPU context). I don't think this is due to the number of path segments, since 4 segments still took 4+ms which seems unacceptable to me.

Not using anti-aliasing seems fine, at least I can't see any jagged corners, but my question is if this should be expected? I know that some forms of anti-aliasing can cause a bit of a performance hit, but this seems excessive. So far I've just been slapping anti-aliasing on anything that isn't drawing rectangles and I'm starting to wonder if I should ever use it with performance impacts like this.

I've tested this on an up to date version of Archlinux and it should be using OpenGL (I did verify that the canvas has a direct context). I should be on a pretty recent version of Skia, Path creation was recently changed to use SkPathBuilder in my bindings (Rust, skia-safe). I've profiled detach/snapshot since I wasn't sure what the 'right' way to build paths is at this point, but it didn't make a difference so I just went with detach for my tests.

Any help/ideas would be appreciated, I'm curious if this is just a device oddity or expected/known.