On Tue, Aug 5, 2014 at 11:21 AM, Justin Novosad <ju...@google.com> wrote:

> On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen <ash...@scirra.com> wrote:
> > I am against this suggestion. If you are serious about performance then
> > you should use WebGL and implement your own batching system, which is
> what
> > every major 2D HTML5 game framework I'm aware of does already. Adding
> > batching features to canvas2d has three disadvantages in my view:
> >
> > 1. Major 2D engines already support WebGL, so even if this new feature
> was
> > supported, in practice it would not be used.
> > 2. There is opportunity cost in speccing something that is unlikely to be
> > used and already well-covered by another part of the web platform. We
> could
> > be speccing something else more useful.
> > 3. canvas2d should not end up being specced closer and closer to WebGL:
> > canvas2d should be kept as a high-level easy-to-use API even with
> > performance cost, whereas WebGL is the low-level high-performance API.
> > These are two different use cases and it's good to have two different
> APIs
> > to cover them. If you want to keep improving canvas2d performance I would
> > worry you will simply end up reinventing WebGL.
> >
> >
> These are good points. The only counter argument I have to that is that a
> fallback from WebGL to canvas2d is unfortunately necessary for a
> significant fraction of users. Even on web-browsers that do support WebGL,
> gl may be emulated in software, which can be detected by web apps and
> warrants falling back to canvas2d (approx. 20% of Chrome users, for
> example). I realize that there is currently a clear ease of use vs.
> performance dichotomy between 2d and webgl, and this proposal blurs that
> boundary. Nonetheless, there is developer-driven demand for this based on a
> real-world problem. Also, if 2D canvas had better performance
> characteristics, it would not be necessary for some game engines to have
> dual (2d/webgl) implementations.
> -Justin

My take is similar to Ashley's, and I wonder how buffing up the toy API
(2D) compensates for the fact that the performance API (GL) has
compatibility problems, even on platforms that support it.  If the goal is
to solve the latter, why not introduce more direct proposals?

Reply via email to