On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote: > On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher <da...@chromium.org> wrote: >> On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth <aba...@webkit.org> wrote: >>> >>> On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin <cmar...@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 cmar...@apple.com _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
