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

On Tue, Aug 5, 2014 at 5:55 PM, Ashley Gullen <ashley@scirra.com> wrote:

> If your argument is that WebGL sometimes falls back to canvas2d, this
> generally only happens when the system has crappy drivers that are
> blacklisted for being insecure/unstable. The solution to this is to develop
> and distribute better drivers that are not blacklisted. This is already
> happening and making good progress - according to Mozilla's stats, Firefox
> users who get WebGL support has increased from 33% in 2011 to 85% in 2014 (
> http://people.mozilla.org/~bjacob/gfx_features_stats/).


As Justin stated, 20% of current Chrome users currently fall back to canvas
2d.
This is a large chunk of the market.
Small developers that don't have the resources to develop for concurrent
WebGL and Canvas2D code paths will certainly code for just Canvas since
that will give them close to 100%.


> I feel it is likely
> to continue to approach ubiquitous WebGL support, making fallbacks
> unnecessary. This also solves the problem of having to have dual renderer
> implementations: only the WebGL renderer will be necessary, and this is far
> more compelling than a souped-up canvas2d, since WebGL can use shader
> effects, have advanced control over textures and co-ordinates, also do 3D,
> and so on. This cannot all be brought to canvas2d without simply
> reinventing WebGL. Further, crappy drivers can also cause software-rendered
> canvas2d as well, which is likely so slow to begin with that batching will
> have no important performance improvement. Software-rendered WebGL is just
> another workaround to crappy drivers (or in rare cases systems without
> GPUs, but then who's going to be gunning for high performance there?) and
> there is still no guarantee falling back to canvas2d will be
> GPU-accelerated, especially since the system already has such poor drivers
> that the browser has blacklisted it for WebGL support.
>
> The real problem is that there is not 100% WebGL support everywhere, but
> with drivers improving and Apple and Microsoft on board I'm sure that will
> fix itself eventually. Please don't spec features to improve canvas2d
> performance in the mean time; I don't see it having any long-term utility
> for the web platform.


When do you envision that OpenGL drivers are bug free everywhere? History
is not on your side here...
I would much rather have something short term that can be implemented with
low effort and improves performance.

I don't really understand why you and Brian are so opposed to improving the
performance of canvas 2D.
There are a lot of people that use and like its API. WebGL on the other
hand, has a very steep learning curve and problems are not always obvious.

Following your logic, why work on new canvas or SVG features as they can
theoretically be emulated in WebGL?
Or now that we have asm.js, why even bother with new JavaScript features?


> On 5 August 2014 16:21, Justin Novosad <junov@google.com> wrote:
>
> > On Mon, Aug 4, 2014 at 6: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?
> > >
> >
> > 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 <kg@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 <ashley@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.
> >
> > -Justin
> >
>

Received on Wednesday, 6 August 2014 18:21:08 UTC