[webkit-dev] Accelerated 2D Tesselation Implementation

[Dong Seong Hwang]

Given all the discussion that had gone on, ACCELERATED_2D_CANVAS was
created using Skia GPU instead of GraphicsContext3D.
Now, ACCELERATED_2D_CANVAS can be used by only Chromium, and
IOSURFACE_CANVAS_BACKING_STORE
is only for Mac.

Is there any plan of other ports similar to ACCELERATED_2D_CANVAS?

And is there any plan for SVG hardware acceleration?

Regards,
Huang.

2010/8/31 Kenneth Russell <kbr at google.com>

> On Mon, Aug 30, 2010 at 1:10 PM, Chris Marrin <cmarrin at apple.com> wrote:
> >
> > 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?
>
> 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.
>
> -Ken
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120303/b173968c/attachment.html>