- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 8 Aug 2014 17:28:20 -0700
- To: Katelyn Gadd <kg@luminance.org>
- Cc: Justin Novosad <junov@google.com>, WHAT Working Group <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
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