On Mar 14, 2010, at 6:22 PM, Jonas Sicking wrote:
One way to do it would be to have an function somewhere, not
necessarily on the 2D context, which given a Blob, returns an
ImageData object. However this still results in the image being loaded
twice into memory, so would only really help if
I agree that the number of steps is not important for responsiveness
or performance (though it is for complexity). However several of those
steps seemed to involved non-trivial amount of CPU usage, that was the
concern expressed in my initial mail.
At the very least I think we have a skewed
On Mar 15, 2010, at 12:28 AM, Jonas Sicking wrote:
=== Conclusions ===
1) For scaling an image up 2x, copying to an ImageData and back for
processing on a Worker would improve responsiveness, relative to
just doing
the scale on the main thread.
2) Copying from one canvas to another is
On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak m...@apple.com wrote:
Copying from one canvas to another is much faster than copying to/from
ImageData. To make copying to a Worker worthwhile as a responsiveness
improvement for rotations or downscales, in addition to the OffscreenCanvas
On Mar 15, 2010, at 3:46 AM, Philip Taylor wrote:
On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak m...@apple.com
wrote:
Copying from one canvas to another is much faster than copying to/
from
ImageData. To make copying to a Worker worthwhile as a responsiveness
improvement for rotations
Am 11. März 2010 14:50 schrieb Michael Nordman micha...@google.com:
On Thu, Mar 11, 2010 at 1:29 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
2010/3/11 Ian Fette (イアンフェッティ) ife...@google.com:
Yes, but I think there may be uses of things like storage for
non-offline
uses (pre-fetching
Am 11. März 2010 14:35 schrieb Mike Shaver mike.sha...@gmail.com:
2010/3/11 Ian Fette (イアンフェッティ) ife...@google.com:
AFAIK most browsers are setting a default quota for storage options that
is
on the order of megabytes.
Could well be, indeed. It sounded like you'd done some thinking about
On 3/15/2010 4:22 AM, Maciej Stachowiak wrote:
On Mar 15, 2010, at 3:46 AM, Philip Taylor wrote:
On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak m...@apple.com
wrote:
Copying from one canvas to another is much faster than copying to/from
ImageData. To make copying to a Worker worthwhile
On Mar 15, 2010, at 2:24 PM, Vladimir Vukicevic wrote:
If we wanted to support this across workers (and I think it would be helpful
to figure out how to do so), something like saying that if a canvas object
was passed (somehow) between workers, it would be a copy -- and internally it
could
Hi all,
Consider a case where I have a SharedWorker script like below, and I
open two tabs that use this SharedWorker. Now myPorts.length is 2. If
I reload one of the two tabs, then myPorts.length is 3, isn't it? But
one of the three ports is already disconnected from the counterpart,
so
On Mon, 15 Mar 2010, ATSUSHI TAKAYAMA wrote:
Consider a case where I have a SharedWorker script like below, and I
open two tabs that use this SharedWorker. Now myPorts.length is 2. If I
reload one of the two tabs, then myPorts.length is 3, isn't it? But one
of the three ports is already
Agreed, there's not a good way to determine that a port is
disentangled. Currently the main solution I know of is to have your document
post a message to your shared worker in their onunload handler.
I think some kind of MessagePort.onclose event or entangled attribute
could be useful - this was
Thanks for replies,
I understood what's the problem here.
The only option that comes to mind that doesn't expose compatibility issues
would be to only issue onclose events if close() is explicitly called on the
entangled port, but if you're doing that you might as well just have the
code
If you don't need to ever broadcast something to all the ports, you can
avoid keeping track of the ports altogether, and then you won't have a
problem. If you do need to broadcast, it's hard not to slowly leak at the
moment.
Even with the example below, port and port.onmessage will be
created
On Mon, 15 Mar 2010, ATSUSHI TAKAYAMA wrote:
If you don't need to ever broadcast something to all the ports, you can
avoid keeping track of the ports altogether, and then you won't have a
problem. If you do need to broadcast, it's hard not to slowly leak at the
moment.
Even with the
15 matches
Mail list logo