On Tue, Apr 14, 2015 at 10:53 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
I guess there are really two different sets of use-cases:
1) Use-cases where the ImageBitmap is sized to fill a particular area of
the screen.
2) Use-cases where the ImageBitmap is sized subject to some other
On Wed, Apr 15, 2015 at 1:15 PM, Kenneth Russell k...@google.com wrote:
If repeatedly transferring ImageBitmaps of the same size into the same
img won't cause repeated re-layouts, that alleviates my concern
about efficiency of using images as the output path. I expect that a
single
On Sun, Apr 12, 2015 at 2:41 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote:
Suppose src=myimage.png is set on an image element and then, while
it is downloading, an ImageBitmap is transferred into it.
This should
I guess there are really two different sets of use-cases:
1) Use-cases where the ImageBitmap is sized to fill a particular area of
the screen.
2) Use-cases where the ImageBitmap is sized subject to some other
constraints, e.g. you're processing an existing image.
For #2, you want the
On Tue, Apr 14, 2015 at 9:03 AM, Justin Novosad ju...@google.com wrote:
On Sun, Apr 12, 2015 at 5:41 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote:
3. Are onload and onerror events fired? This question applies
On Sun, Apr 12, 2015 at 5:41 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote:
3. Are onload and onerror events fired? This question applies both to
the in-progress download and to the transferred-in ImageBitmap.
No.
On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote:
Suppose src=myimage.png is set on an image element and then, while
it is downloading, an ImageBitmap is transferred into it.
This should behave as if src was removed just before the ImageBitmap is
transferred into it.
In
On Mon, Apr 13, 2015 at 9:41 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell k...@google.com wrote:
5. Can the developer go back to having the img element contain what
was set on 'src' and not what was transferred in?
As written, yes, by
On Sat, Apr 11, 2015 at 2:18 AM, Justin Novosad ju...@google.com wrote:
Riddle me this: What would be the value an HTMLImageElement's src attribute
after an ImageBitmap is transferred in? A data URL? What if the ImageBitmap
was sourced from an actual resource with a URL, would we pipe that
On Thu, Apr 9, 2015 at 6:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Apr 9, 2015 at 5:23 PM, Kenneth Russell k...@google.com wrote:
1. An image element that didn't have a width or height explicitly
specified in the markup has an ImageBitmap transferred in. Will its
width and
On Fri, Apr 10, 2015 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Sat, Apr 11, 2015 at 2:18 AM, Justin Novosad ju...@google.com wrote:
Riddle me this: What would be the value an HTMLImageElement's src
attribute
after an ImageBitmap is transferred in? A data URL? What if the
(sorry for double email) Just one question about how requestAnimationFrame
is expected to work. Could we get rAF added to workers? Would it be able to
simply fire whenever it does on the main thread, as if it postMessage'd to
the worker every time it was called but without the extra postMessage
Noteworthy: The OffscreenCanvas proposal removes a lot of the friction that
we had with the toBlob implementation.
On Tue, Apr 7, 2015 at 9:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Wed, Apr 8, 2015 at 11:41 AM, Kenneth Russell k...@google.com wrote:
I apologize for taking so
This looks like it will cover running a HTML5 game engine from a worker
very nicely and with little performance overhead. Good stuff!
Ashley
On 8 April 2015 at 00:41, Kenneth Russell k...@google.com wrote:
On Wed, Mar 25, 2015 at 6:41 PM, Kenneth Russell k...@google.com wrote:
On Wed, Mar
On Thu, Apr 9, 2015 at 9:44 AM, Kenneth Russell k...@google.com wrote:
On Tue, Apr 7, 2015 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
As far as I can tell, the only significant difference between
this and WorkerCanvas is using an HTMLCanvasElement bitmaprenderer as a
On Tue, Apr 7, 2015 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Apr 8, 2015 at 11:41 AM, Kenneth Russell k...@google.com wrote:
I apologize for taking so long to update this proposal, but it's now
in a reasonable state:
https://wiki.whatwg.org/wiki/OffscreenCanvas
On Wed, Apr 8, 2015 at 8:46 AM, Ashley Gullen ash...@scirra.com wrote:
(sorry for double email) Just one question about how requestAnimationFrame
is expected to work. Could we get rAF added to workers? Would it be able to
simply fire whenever it does on the main thread, as if it postMessage'd
On Wed, Mar 25, 2015 at 6:41 PM, Kenneth Russell k...@google.com wrote:
On Wed, Mar 25, 2015 at 1:22 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Wed, Mar 25, 2015 at 11:41 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
On Wed, Apr 8, 2015 at 11:41 AM, Kenneth Russell k...@google.com wrote:
I apologize for taking so long to update this proposal, but it's now
in a reasonable state:
https://wiki.whatwg.org/wiki/OffscreenCanvas
(Renamed per feedback from Anne -- thanks.)
Please offer your feedback. Multiple
Sorry for arriving so late to the party...
I would like to update this thread on what has been happening around
canvas.toBlob in Blink.
First of all, there was an attempt at implementing canvas.toBlob a couple
years ago, back when Chromium was using WebKit. The experience revealed
that the API
On Wed, Mar 25, 2015 at 4:28 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Mar 26, 2015 at 8:40 AM, Justin Novosad ju...@google.com wrote:
Eliminating the transit through canvas also
allows for fast paths for capturing blobs from video, img, svg, URLs,
to name a few.
With new
On Thu, Mar 26, 2015 at 9:43 AM, Justin Novosad ju...@google.com wrote:
createImageBitmap(myImageSource).then(function (image) {
image.toBlob().then(admireYourShinyNewBlob); });
Oh, right. Sorry! Of course :-).
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
On Wed, Mar 25, 2015 at 11:41 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
My understanding is that the current consensus proposal for canvas in
Workers is not what's in the spec, but this:
On Thu, Mar 26, 2015 at 8:40 AM, Justin Novosad ju...@google.com wrote:
One idea we've been brewing that has not surfaced on this thread so far is
that of having an ImageBitmap.toBlob(), which would return a Promise. Also,
ImageBitmap should be transferable. This idea is just partially baked
On Wed, Mar 25, 2015 at 1:22 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Mar 25, 2015 at 11:41 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
My understanding is that the current consensus proposal
On Fri, Mar 20, 2015 at 11:15 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
My understanding is that the current consensus proposal for canvas in
Workers is not what's in the spec, but this:
https://wiki.whatwg.org/wiki/WorkerCanvas
See Canvas in Workers threads from October 2013 for the
On 3/21/15, Jake Archibald jaffathec...@gmail.com wrote:
I'd rather we did that by introducing promises to HTMLCanvasElement.
Returning a promise from toBlob is easy, making the callback arg optional
by checking the type of the first arg is hacky but possible (and is done in
js libs).
On 3/23/15, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 3/21/15, Jake Archibald jaffathec...@gmail.com wrote:
[...]
https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0059.html
Sorry, this was the actual post:
I'd rather Firefox did a small hack under hood for compatibility than we
hack the spec with a separate method.
We shouldn't be adding async APIs to browsers that use callbacks. Only one
browser implements the callback version here, and they can maintain compat
easily remove the callback when
Which is why more browsers shouldn't adopt it. If we have an opportunity to
switch it for a promise-based API, we should take it.
On Mon, 23 Mar 2015 at 17:21 Garrett Smith dhtmlkitc...@gmail.com wrote:
On 3/23/15, Jake Archibald jaffathec...@gmail.com wrote:
I'd rather Firefox did a small
On 3/23/15, Jake Archibald jaffathec...@gmail.com wrote:
I'd rather Firefox did a small hack under hood for compatibility than we
hack the spec with a separate method.
We shouldn't be adding async APIs to browsers that use callbacks.
Not sure what you mean. Method toBlob is async and uses a
On Sat, Mar 21, 2015 at 11:02 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sun, Mar 22, 2015 at 6:45 PM, Rik Cabanier caban...@gmail.com wrote:
On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier
On Sat, 21 Mar 2015 at 18:16 Rik Cabanier caban...@gmail.com wrote:
Justin is worried that in order to make this asynchronous, Chrome has to
create a snapshot of the canvas bits which is slow if it resides on the GPU.
Of course, his workaround to use getImageData is just as slow since it has
I'm getting confused as to what the problem is.
To restate the advantages of async toBlob: suppose I have code that does
drawStuffTo(context);
context.canvas.toBlob().then(callback);
// no further drawing to the canvas
This has a few advantages over using getImageData and then encoding to
On Sun, Mar 22, 2015 at 6:45 PM, Rik Cabanier caban...@gmail.com wrote:
On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier caban...@gmail.com
wrote:
Justin is worried that in order to make this asynchronous,
On Sat, Mar 21, 2015 at 4:19 AM, Jake Archibald jaffathec...@gmail.com
wrote:
I'd rather we did that by introducing promises to HTMLCanvasElement.
Returning a promise from toBlob is easy, making the callback arg optional
by checking the type of the first arg is hacky but possible (and is done
Is everyone here aware that currently Google have stated they do not plan
to implement toBlob?:
https://code.google.com/p/chromium/issues/detail?id=67587
IMO this is the wrong call. We should be favouring blobs over data URLs
since they are more efficient (no size bloat, can be requested async
On Sat, Mar 21, 2015 at 5:45 PM, Rik Cabanier caban...@gmail.com wrote:
Ah, OK. I thought we were changing it for both cases. This will cause a lot
of confusion...
If we want to keep HTMLCanvasElement and WorkerCanvas in sync, we can.
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo
I'd rather we did that by introducing promises to HTMLCanvasElement.
Returning a promise from toBlob is easy, making the callback arg optional
by checking the type of the first arg is hacky but possible (and is done in
js libs).
On Sat, 21 Mar 2015 10:56 Robert O'Callahan rob...@ocallahan.org
On Sat, Mar 21, 2015 at 6:21 AM, Ashley Gullen ash...@scirra.com wrote:
Is everyone here aware that currently Google have stated they do not plan
to implement toBlob?:
https://code.google.com/p/chromium/issues/detail?id=67587
IMO this is the wrong call. We should be favouring blobs over data
On Sat, Mar 21, 2015 at 1:44 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sun, Mar 22, 2015 at 7:16 AM, Rik Cabanier caban...@gmail.com wrote:
Justin is worried that in order to make this asynchronous, Chrome has to
create a snapshot of the canvas bits which is slow if it resides on
On Fri, Mar 20, 2015 at 3:15 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Mar 21, 2015 at 1:13 AM, Jake Archibald jaffathec...@gmail.com
wrote:
Receiving a push message results in a 'push' event within the
ServiceWorker. The likely action at this point is to show a
On 3/20/15 8:13 AM, Jake Archibald wrote:
Almost all the pieces already exist, except a way to get the image data of
a CanvasRenderingContext2D into a format that can be read from a
url.
There's CanvasRenderingContext2D.toDataURL; I assume the problem is that
it's not async, yes? But if
On 3/20/15 8:53 AM, Kenji Baheux wrote:
I believe that toDataURL is on Canvas not CanvasRenderingContext2D.
https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2d
The CanvasRenderingContext2D.canvas being null, there is no way to use it.
Oh. Yeah, that's silly; we
+1 I've tried to workaround the limitation with some pureJS libraries (such
as http://todataurl-png-js.googlecode.com/svn/trunk/todataurl.js) but
having a native implementation would be so much better.
I believe that toDataURL is on Canvas not CanvasRenderingContext2D.
https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2d
The CanvasRenderingContext2D.canvas being null, there is no way to use it.
On Fri, Mar 20, 2015 at 9:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Mar 21, 2015 at 3:38 PM, Rik Cabanier caban...@gmail.com wrote:
Do you know how many site use toBlob in Firefox?
A quick search on github shows a very high number of pages [1] so it
might be too late to
On Sat, Mar 21, 2015 at 3:38 PM, Rik Cabanier caban...@gmail.com wrote:
Do you know how many site use toBlob in Firefox?
A quick search on github shows a very high number of pages [1] so it might
be too late to change.
Maybe you can keep the callback and return a promise?
None of them use
Usecase:
Receiving a push message results in a 'push' event within the
ServiceWorker. The likely action at this point is to show a notification.
It should be possible to generate an image to use as an icon for this
notification (
On Sat, Mar 21, 2015 at 1:13 AM, Jake Archibald jaffathec...@gmail.com
wrote:
Receiving a push message results in a 'push' event within the
ServiceWorker. The likely action at this point is to show a notification.
It should be possible to generate an image to use as an icon for this
50 matches
Mail list logo
