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.

As developers of a HTML5 game engine with WebGL support and fallback to
canvas2d, this has no utility to us at all. It would be more useful to work
on WebGL 2.

Ashley Gullen

On 5 August 2014 00:35, Katelyn Gadd <k...@luminance.org> wrote:

> Many, many uses of drawImage involve transform and/or other state
> changes per-blit (composite mode, global alpha).
> I think some of those state changes could be viably batched for most
> games (composite mode) but others absolutely cannot (global alpha,
> transform). I see that you handle transform with
> source-rectangle-and-transform (nice!) but you do not currently handle
> the others. I'd suggest that this needs to at least handle
> globalAlpha.
> Replacing the overloading with individual named methods is something
> I'm also in favor of. I think it would be ideal if the format-enum
> argument were not there so that it's easier to feature-detect what
> formats are available (for example, if globalAlpha data is added later
> instead of in the '1.0' version of this feature).
> 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.
> if rgba multiplication were to make it into canvas2d sometime in the
> next decade, that would nicely replace globalAlpha as a per-draw
> value. This is an analogue to per-vertex colors in 3d graphics and is
> used in virtually every hardware-accelerated 2d game out there,
> whether to tint characters when drawing text, fade things in and out,
> or flash the screen various colors. That would be another reason to
> make feature detection easier.
> 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.
> On the bright side there's a workaround for RGBA multiplication based
> on generating per-channel bitmaps from the source bitmap (k, r/g/b),
> then blending them source-over/add/add/add. drawImageBatch would
> improve perf for the r/g/b part of it, so it's still an improvement.
> On Mon, Aug 4, 2014 at 3:39 PM, Robert O'Callahan <rob...@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?
> >
> > 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?
> >
> > Rob
> > --
> > oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> > owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> > osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> > owohooo
> > osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> > oioso
> > oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> > owohooo
> > osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
> > ooofo
> > otohoeo ofoioroeo ooofo ohoeololo.

Reply via email to