Bug 202260 – Bad performance when drawing bezier paths into a canvas

• Status: NEW
• Component: Canvas

When using CanvasRenderingContext2D to draw complex paths we've noticed huge drop in performance when calling .closePath(). We were able to narrow down the issue to cases when there is a path containing bezier segments. When profiling, the performance of drawing a complex 2d graphics using beziers in closed paths is 30000x worse than using just line segments (5080ms vs 0.17ms). Looking at the source code of closePath method it seems like there is an overkill call to calculate bounding rects in https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/canvas/CanvasPath.cpp

void CanvasPath::closePath()
{
    if (m_path.isEmpty())
        return;

    FloatRect boundRect = m_path.fastBoundingRect();    <-----   this seems to be the performance issue, the 'fast' prefix is a lie
    if (boundRect.width() || boundRect.height())
        m_path.closeSubpath();
}

To find out whether path has 'zero' size one does not need to calculate an exact bounding rect or does he?

[Alexey Proskuryakov]

Could you please provide a complete test case?

[Radar WebKit Bug Importer]

<rdar://problem/55823687>

Created attachment 379825 [details]
Rendering closed paths containg beziers

The test_beziers.html contains a very much narrowed down case - closePath is called on paths containing bezier segments. If you comment out lines 28-30 and uncomment lines 24-26 it's much much quicker (when no beziers are used)

We developed a workaround where we flatten all beziers using Casteljau algorithm prior to closing the paths. Even though the amount of computation seems very high, this method is much quicker than just closing the path containing beziers.

[Simon Fraser (smfr)]

It's still really slow even with the closePath() commented out. This is a perf issue in a framework below WebKit.

@Simon are you 100% sure? Because when I comment out closePath line I get boost of fps from 1.5 to 32 with beziers. Just rechecked this as your comment stunned me.

[Simon Fraser (smfr)]

The closePath() certainly adds some overhead, but the bezier drawing itself is still very expensive. We can keep this bug open to optimize the closePath() case.

[Ahmad Saleem]

I just tested this again and Safari Technology Preview 183 is performing better than Safari 17.1.2.