> As Justin stated, 20% of current Chrome users currently fall back to
> canvas 2d.

1. What fraction of those 20% actually still get a GPU accelerated canvas
vs. software rendered? Batching will be of very little use to the software
rendered audience, making it an even smaller target market.
2. In Firefox's case, that number has reduced from 67% to 15% over a couple
of years. Surely in time this will fall even further to a negligible
amount. Why standardise a feature whose target market is disappearing?

> Small developers that don't have the resources to develop for concurrent
> WebGL and Canvas2D code paths

They don't have to: there are free, high-quality open-source libraries like
Pixi.js that do this already, so even "small" developers have an easy way
to make use of a WebGL renderer without much extra effort.

> When do you envision that OpenGL drivers are bug free everywhere? History
> is not on your side here...
> I would much rather have something short term that can be implemented with
> low effort and improves performance.

No software is ever bug-free, but this is irrelevant. To not be
blacklisted, drivers don't need to be perfect, they just need to meet a
reasonable threshold of security and reliability. If a driver is insecure
or crashes constantly it is blacklisted. Drivers are being improved so they
are no longer this poor, and it is not unrealistic to imagine 99%+ of
drivers meeting this threshold in the near future, even if none of them are
completely bug-free.

> I don't really understand why you and Brian are so opposed to improving
> the performance of canvas 2D.

I see it as a feature targeted at a rapidly disappearing segment of the
market that will disappear in the long run, leaving the web platform with
unnecessary API cruft.

> Following your logic, why work on new canvas or SVG features as they can
> theoretically be emulated in WebGL?
> Or now that we have asm.js, why even bother with new JavaScript features?

I am in general against duplication on the web platform, but new features
deserve to be implemented if they have a valid use case or solve a real
problem. In this case I don't see that any real problem is being solved,
since widely available frameworks and engines already solve it with WebGL
in a way accessible even to individual developers, and this solution is
already production-grade and widely deployed.

On further thought this particular proposal doesn't even appear to solve
the batching problem very well. Many games consist of large numbers of
rotated sprites. If a canvas2d batching facility needs to break the batch
every time it needs to call rotate(), this will revert back to individual
draw-calls for many kinds of game. WebGL does not have this limitation and
can batch in to single calls objects of a variety of scales, angles,
tiling, opacity and more. This is done by control over individual vertex
positions and texture co-ordinates, which is a fundamental break from the
style of the canvas2d API. Therefore even with the proposed batching
facility, for maximum performance it is still necessary to use WebGL. This
proposal solves a very narrowly defined performance problem.

An alternate solution is for browser vendors to implement canvas2d entirely
in JS on top of WebGL. This reduces per-call overhead by staying in JS
land, while not needing to add any new API surface. In fact it looks like
this has already been attempted here:
https://github.com/corbanbrook/webgl-2d - I'd suggest before speccing this
feature that it is researched whether the same performance goals can be
achieved with a well-batched JS implementation which reduces the number of
calls in to the browser, which is exactly how existing WebGL renderers
outperform canvas2d despite both being GPU accelerated.


Reply via email to