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

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

Received on Monday, 4 August 2014 23:36:11 UTC