Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage

On Fri, Aug 8, 2014 at 7:25 AM, Ashley Gullen <ashley@scirra.com> wrote:

> 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.
>

There will still be a noticeable gain since we wouldn't have to cross the
JS boundary as much.
More importantly though, things will still work for non-accelerated canvas
while WebGL won't.


> 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?
>

How long will it be before we're at a reliable 100%? Graphics drivers are
still flaky and it's not as if they only came out a couple of years ago.
Note that the supported % for graphics "layers" (accelerated compositing)
is much lower.


> 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 think Justin can better fill you in on this. Chrome has to jump through
many hoops to make canvas reliable on top of OpenGL and it still suffers
from random crashes when you stress the system.
Both Safari and Firefox use higher level system calls and are more reliable
(albeit slower) than Chrome.


> 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.
>

The problem is that a large number of drawImage calls have a lot of
overhead due to JS crossings and housekeeping. This proposal solves that.


> 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.
>

Sure, but that is in WebGL which not everyone wants to use and is less
widely supported.


> 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.
>

I'm unsure if I follow. The point of Justin's proposal is to do just that
under the hood.
Why do you think the batching needs to be broken up? Did you see that the
proposal has a matrix per draw?


> 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 -
>

Implementing Canvas on top of WebGL is not realistic.
Please look into Chrome's implementation to make canvas reliable and fast.
This can not be achieved today.

I totally agree if the web platform matures to a point where this IS
possible, we should just freeze canvas development.


> 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.
>

Now I'm very confused. That IS Justin's proposal.

Received on Saturday, 9 August 2014 00:43:50 UTC