[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Disable software rendering

----- Original Message -----
> >
> > Or here's a different approach: add a new method on the Canvas
> > element (so, alongside getContext) that would take two context ids
> > and return a recommendation of which is likely to be faster for
> > typical tasks that could be done with either.
> >
> > User code would look like:
> >
> > var contexttype = canvas.whichIsLikelyFaster("experimental-webgl",
> > "2d");
> > var context = canvas.getContext(contexttype);
> >
> > In this example, since the two strings are "experimental-webgl" and
> > "2d", the question is which one is faster for things that can
> > typically be done with either, which in this case means basic 2d
> > graphics with sprites a la Angry Birds. Typically here one would
> > return webgl if it's accelerated, 2d otherwise. My assumption here
> > is that software WebGL renderers would have a hard time matching a
> > good software canvas2d implementation, I could be wrong.
> I don't really like this idea as it is basically assuming that the 2d
> context must be slower than the webgl context for some 2d scenarios. I
> would argue that if there is a 2d use case where webgl is faster than
> the 2d context by a significant magnitude then that's an
> implementation problem in the UA, especially given all the reasons
> that can lead to a user being unable to use webgl (security black
> lists, etc)

I really defend the opinion that the 2d context is inherently  slower than WebGL for many usual 2d scenarios on usual hardware-accelerated setups. The simplest and most important example is plain 2d sprites. Whis Canvas2D you must do one drawImage call per sprite, while with WebGL you can render all your sprites in a single draw-call. That alone allowed Jeff Muizelaar to write a WebGL port of IE9's FishIE demo that ran much faster with many more fish than the original:


Really, the 2d context is an evolution of postscript, it never was meant for high-performance realtime graphics.

Now if you throw float textures and vertex-shader-texture-lookup into the mix (admittedly not yet universally supported) you can even perform sprites coordinates updates on the GPU, eliminating the vertex data transfers on every frame, making it even faster than in Jeff's post.

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl