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

On Thu, Aug 7, 2014 at 7:11 PM, Katelyn Gadd <kg@luminance.org> wrote:

> Sorry, in this context rgba multiplication refers to per-channel
> multipliers (instead of only one multiplier for the alpha channel), so
> that you can color tint images when drawing them. As mentioned, it's
> used for fades, drawing colored text, and similar effects.
>

I see. Any reason that this couldn't be done with a 'multiply' blend mode?


> Premultiplication is a different subject, sorry if I confused you with
> the similar language. There are past discussions about both in the
> list archives.
>
> On Thu, Aug 7, 2014 at 10:59 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> >
> >
> >
> > 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 Saturday, 9 August 2014 00:28:46 UTC