[webkit-dev] Accelerated 2D Tesselation Implementation

Chris Marrin cmarrin at apple.com
Sat Aug 28 07:44:48 PDT 2010

On Aug 27, 2010, at 5:32 PM, Kenneth Russell wrote:

>> ...
>> So here's my concern. If you have to multisample for anti-aliasing anyway, why not just tesselate the shape at an appropriate sampling resolution and multisample the resulting triangle rendering. That would have the disadvantage of not being resolution independent, but it would be much simpler. And you can control the re-tessellation by oversampling the curve and only re-tesselating every few frames (maybe in the background) or only re-tesselating when not animating, or something like that. Would it be significantly faster or slower? Would the quality be better or worse? We'd have to run some tests. I just don't want to jump into a big expensive algorithm when something simpler would suffice.

> ...
> I definitely do not want to commit the WebKit project to using this
> particular algorithm and none other. I suspect we will need to
> investigate multiple approaches for GPU accelerating path rendering.
> That having been said, there is ongoing work to accelerate 2D canvas
> rendering using the GPU, and it has been determined that path
> rendering is a major bottleneck on some benchmarks. We believe that
> this algorithm will help eliminate this bottleneck. In order to
> continue our GPU accelerated canvas work, it is essential that the
> work continue on the WebKit trunk, where it is currently ongoing. We
> can not maintain a fixed branch of both the Chromium and WebKit
> projects, especially as other GPU infrastructure work is actively
> ongoing in both.
> I am committed to making this code work well in the WebKit
> infrastructure, and am not wedded to the particular algorithm; if a
> better one comes along, let's switch to it.
> Please work with me to find a way forward that is mutually acceptable.

That's what we're doing now :-)

I think the way forward is two-fold: 1) decide that this is the best algorithm to use and 2) decide how best to include all the parts in WebKit. We need to do (1) before (2). For (1) there are still some open issues: a) solve the anti-aliasing issue (showing the results, 2) understand and fix the cracking issues (may just have to add stroking or something) and c) understand the performance.

That's why I still think this should all go into a branch for now. It will help us all see the results without having to deal with the issues of (2) right now.

cmarrin at apple.com

More information about the webkit-dev mailing list