On Mon, Aug 4, 2014 at 6:39 PM, Robert O'Callahan <rob...@ocallahan.org>

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

Composited separately is the intent. A possible internal optimization: the
implementation could group non-overlapping draw and composite them together.

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

Had not thought of that. Good idea.

On Mon, Aug 4, 2014 at 7:35 PM, Katelyn Gadd <k...@luminance.org> wrote:

> I'd suggest that this needs to at least handle
> globalAlpha.

It would be trivial to add a an addition format that includes alpha.

> Replacing the overloading with individual named methods is something
> I'm also in favor of.

That's something I pondered and was not sure about. Eliminating the
parameter format argument would be nice. Your feature-detection argument is
a really good reason.

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

I am not sure exposing that in the API is a good idea because it opens the
door to undefined behavior. It could result in different implementations
producing drastically different yet compliant results.
Perhaps implementations could auto-detect draw operations that are
commutative based on a quick overlap analysis, and use that knowledge to
automatically group draw calls that use similar drawing state (e.g. the
same source GPU texture)

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

I think that would make this feature significantly more complex to spec,
and to implement. It really should be treated as an orthogonal feature
request. Your suggestion is very use-case specific. A more general
incarnation of your request would be to have a blendMode parameter that
that determines how the source image gets blended with the fillStyle. With
that, you resolve your specific use case by setling the fill style to an
rgba color, and using a multiply blend op to use it to modulate images.

On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen <ash...@scirra.com> wrote:

> 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.
These are good points. The only counter argument I have to that is that a
fallback from WebGL to canvas2d is unfortunately necessary for a
significant fraction of users. Even on web-browsers that do support WebGL,
gl may be emulated in software, which can be detected by web apps and
warrants falling back to canvas2d (approx. 20% of Chrome users, for
example). I realize that there is currently a clear ease of use vs.
performance dichotomy between 2d and webgl, and this proposal blurs that
boundary. Nonetheless, there is developer-driven demand for this based on a
real-world problem. Also, if 2D canvas had better performance
characteristics, it would not be necessary for some game engines to have
dual (2d/webgl) implementations.


Reply via email to