On Mon, Aug 30, 2010 at 1:10 PM, Chris Marrin <cmarrin@...> wrote:
> On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote:
>> On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher <darin@...> wrote:
>>> On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth <abarth@...> wrote:
>>>> On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin <cmarrin@...> 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.
>>> 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
>> 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?
Multisampling doesn't handle the pixels covering the cubic curves. The
fragment shader is only run once per pixel, so to get antialiasing for
these regions with this algorithm, it's necessary to compute the
distance function to the curve in the shader.