Sweet, I think we're on the same page. I completely agree with your high
level goal of a declarative fetch interface.
Agreed that matching is still critical, eg for the Link header use case.
On Thu, Aug 7, 2014 at 10:40 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Thu, Aug 7, 2014 at
+1 to breaking the dependency between fetching the resource and how it is later
used in the document. This type of “late binding” enables many page
optimizations.
Peter
PS. My apologies if you’ve already seen a message saying similar. I’m not sure
if the mailing list is accepting my messages
Hi Andrew,
On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com wrote:
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com
wrote:
I understand your concern that is driving this
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 Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo bever...@google.com wrote:
I think the benefit of being able to closely match the UI and UX of native
notifications on the platforms is something that's enabled by using
declarative properties, whereas that would be near impossible to do with
HTML
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
14 matches
Mail list logo
