[webkit-dev] Accelerated 2D Tesselation Implementation

[Chris Marrin]

On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote:

> On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher <darin at chromium.org> wrote:
>> On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth <abarth at webkit.org> wrote:
>>> 
>>> On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin <cmarrin at apple.com> wrote:
>>>> 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.
>>> 
>>> An alternative to a branch is to use a run-time setting.  That worked
>>> well for the HTML5 parser project.  If there's a clean abstraction
>>> boundary in the code, we can use that as the branch point for the
>>> setting.  The advantage of using a run-time setting is that you can
>>> leverage all the tools for working on trunk (including code reviews,
>>> etc) but you can avoid disturbing the vast majority of other
>>> developers while your feature bakes.
>>> 
>>> Adam
>> 
>> Such a runtime setting already exists for toggling accelerated canvas 2d on
>> and off.
> 
> This GPU based path rendering support is initially only going to be
> hooked in to the accelerated 2D canvas implementation, which since
> it's already covered by this run-time flag will not disturb other
> developers.
> 
> I am going to substantially restructure the code based on feedback and
> submit new patches, but still against trunk.

Given all the discussion that has gone on, I agree that trunk is the right place to do this. But I remain concerned about antialiasing.

On that subject. If you were to have to do multi-sampling to solve the AA problem, does it make sense to skip the anti-aliasing on the edges of the spline triangles? Would that buy any performance?

-----
~Chris
cmarrin at apple.com