- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 6 Aug 2014 11:04:45 -0700
- To: Brian Blakely <anewpage.media@gmail.com>
- Cc: Justin Novosad <junov@google.com>, WHAT Working Group <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Tue, Aug 5, 2014 at 10:04 AM, Brian Blakely <anewpage.media@gmail.com> wrote: > On Tue, Aug 5, 2014 at 11:21 AM, Justin Novosad <junov@google.com> wrote: > > > On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen <ashley@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? > Can you explain what you're asking for? Are you asking for a proposal that fixes compatibility?
Received on Wednesday, 6 August 2014 18:05:18 UTC