As Justin stated, 20% of current Chrome users currently fall back to
canvas 2d.
1. What fraction of those 20% actually still get a GPU accelerated canvas
vs. software rendered? Batching will be of very little use to the software
rendered audience, making it an even smaller target market.
2.
On Fri, Aug 8, 2014 at 10:25 AM, Ashley Gullen ash...@scirra.com wrote:
As Justin stated, 20% of current Chrome users currently fall back to
canvas 2d.
1. What fraction of those 20% actually still get a GPU accelerated canvas
vs. software rendered? Batching will be of very little use to the
1. What fraction of those 20% actually still get a GPU accelerated canvas
vs. software rendered? Batching will be of very little use to the software
rendered audience, making it an even smaller target market.
~25% of Chrome users that do not have gpu-accelerated WebGL do have gpu
On Thu, Aug 7, 2014 at 7:11 PM, Katelyn Gadd k...@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,
On Fri, Aug 8, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote:
As Justin stated, 20% of current Chrome users currently fall back to
canvas 2d.
1. What fraction of those 20% actually still get a GPU accelerated canvas
vs. software rendered? Batching will be of very little use to the
On 8/8/14, 8:43 PM, Rik Cabanier wrote:
The problem is that a large number of drawImage calls have a lot of
overhead due to JS crossings and housekeeping.
Could we please quantify this?
I measured the JS crossings part of this, because it's easy: Just have
the C++ side of drawImage return
The way you measured the JS crossing time does not include parameter
validations if I am not mistaken. If you have 1000 sprite draws that draw
from the same sprite sheet, that is 1000 times you are verifying the same
image parameter (verifying that the image is complete, that its security
origin
On 8/8/14, 9:46 PM, Justin Novosad wrote:
The way you measured the JS crossing time does not include parameter
validations if I am not mistaken.
It includes the validation Web IDL does (e.g. this is an
HTMLImageElement) but not the specific validation this method does,
correct.
If you
A multiply blend mode by itself is not sufficient because the image
being rgba multiplied typically has alpha transparency. The closest
approximation is to generate (offline, in software with getImageData)
an image per channel - rgbk - and to source-over blend the 'k' channel
and then additive
On Fri, Aug 8, 2014 at 7:54 PM, Katelyn Gadd k...@luminance.org wrote:
A multiply blend mode by itself is not sufficient because the image
being rgba multiplied typically has alpha transparency. The closest
approximation is to generate (offline, in software with getImageData)
an image per
On Mon, Aug 4, 2014 at 4:35 PM, Katelyn Gadd k...@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
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.
Premultiplication is a different
On Tue, Aug 5, 2014 at 10:04 AM, Brian Blakely anewpage.me...@gmail.com
wrote:
On Tue, Aug 5, 2014 at 11:21 AM, Justin Novosad ju...@google.com wrote:
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
On Tue, Aug 5, 2014 at 5:55 PM, Ashley Gullen ash...@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
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
On Mon, Aug 4, 2014 at 6:39 PM, Robert O'Callahan rob...@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
On Tue, Aug 5, 2014 at 11:21 AM, Justin Novosad ju...@google.com wrote:
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
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
Greetings all,
In a drive to satisfy some the most demanding performance critical
applications--2d platformer games--, browser vendors have put a lot of
effort into optimizing CanvasRenderingContext2D, and the drawImage method
in particular. In a world where browsers have GPU-accelerated graphics
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
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
21 matches
Mail list logo