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

If your argument is that WebGL sometimes falls back to canvas2d, this
generally only happens when the system has crappy drivers that are
blacklisted for being insecure/unstable. The solution to this is to develop
and distribute better drivers that are not blacklisted. This is already
happening and making good progress - according to Mozilla's stats, Firefox
users who get WebGL support has increased from 33% in 2011 to 85% in 2014 (
http://people.mozilla.org/~bjacob/gfx_features_stats/). I feel it is likely
to continue to approach ubiquitous WebGL support, making fallbacks
unnecessary. This also solves the problem of having to have dual renderer
implementations: only the WebGL renderer will be necessary, and this is far
more compelling than a souped-up canvas2d, since WebGL can use shader
effects, have advanced control over textures and co-ordinates, also do 3D,
and so on. This cannot all be brought to canvas2d without simply
reinventing WebGL. Further, crappy drivers can also cause software-rendered
canvas2d as well, which is likely so slow to begin with that batching will
have no important performance improvement. Software-rendered WebGL is just
another workaround to crappy drivers (or in rare cases systems without
GPUs, but then who's going to be gunning for high performance there?) and
there is still no guarantee falling back to canvas2d will be
GPU-accelerated, especially since the system already has such poor drivers
that the browser has blacklisted it for WebGL support.

The real problem is that there is not 100% WebGL support everywhere, but
with drivers improving and Apple and Microsoft on board I'm sure that will
fix itself eventually. Please don't spec features to improve canvas2d
performance in the mean time; I don't see it having any long-term utility
for the web platform.

Ashley



On 5 August 2014 16:21, Justin Novosad <junov@google.com> wrote:

> On Mon, Aug 4, 2014 at 6:39 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> > It looks reasonable to me.
> >
> > How do these calls interact with globalAlpha etc? You talk about
> > decomposing them to individual drawImage calls; does that mean each image
> > draw is treated as a separate composite operation?
> >
>
> Composited separately is the intent. A possible internal optimization: the
> implementation could group non-overlapping draw and composite them
> together.
>
>
> > Currently you have to choose between using a single image or passing an
> > array with one element per image-draw. It seems to me it would be more
> > flexible to always pass an array but allow the parameters array to refer
> to
> > an image by index. Did you consider that approach?
> >
>
> Had not thought of that. Good idea.
>
> On Mon, Aug 4, 2014 at 7:35 PM, Katelyn Gadd <kg@luminance.org> wrote:
>
> > I'd suggest that this needs to at least handle
> > globalAlpha.
> >
>
> It would be trivial to add a an addition format that includes alpha.
>
>
> > Replacing the overloading with individual named methods is something
> > I'm also in favor of.
>
>
> That's something I pondered and was not sure about. Eliminating the
> parameter format argument would be nice. Your feature-detection argument is
> a really good reason.
>
> >
> > I get the impression that ordering is implicit for this call - the
> > batch's drawing operations occur in exact order. It might be
> > worthwhile to have a way to indicate to the implementation that you
> > don't care about order, so that it is free to rearrange the draw
> > operations by image and reduce state changes. Doing that in userspace
> > js is made difficult since you can't easily do efficient table lookup
> > for images.
> >
>
> I am not sure exposing that in the API is a good idea because it opens the
> door to undefined behavior. It could result in different implementations
> producing drastically different yet compliant results.
> Perhaps implementations could auto-detect draw operations that are
> commutative based on a quick overlap analysis, and use that knowledge to
> automatically group draw calls that use similar drawing state (e.g. the
> same source GPU texture)
>
>
> >
> > Would it be possible to sneak rgba multiplication in under the guise
> > of this feature? ;) Without it, I'm forced to use WebGL and reduce
> > compatibility just for something relatively trivial on the
> > implementer's side. (I should note that from what I've heard, Direct2D
> > actually makes this hard to implement.
> >
>
> I think that would make this feature significantly more complex to spec,
> and to implement. It really should be treated as an orthogonal feature
> request. Your suggestion is very use-case specific. A more general
> incarnation of your request would be to have a blendMode parameter that
> that determines how the source image gets blended with the fillStyle. With
> that, you resolve your specific use case by setling the fill style to an
> rgba color, and using a multiply blend op to use it to modulate images.
>
> 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
>

Received on Wednesday, 6 August 2014 00:56:22 UTC