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

On Mon, Aug 4, 2014 at 4:35 PM, Katelyn Gadd <kg@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).
>

We can define the functions so they throw a type error if an unknown enum
is passed. That way you can feature detect future additions to the enum.

What should be do about error detection in general? If we require the float
array to be well formed before drawing, we need an extra pass to make sure
that they are correct.
If we don't require it, we can skip that pass but content could be
partially drawn to the canvas before the exception is thrown.


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

Is this the other proposal to control the format of the canvas buffer that
is passed to WebGL?


> 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 Thursday, 7 August 2014 17:59:41 UTC