On 15/01/2011, at 17:57, Simon Pieters wrote:
On Fri, 14 Jan 2011 12:04:03 +0100, Jorge jo...@jorgechamorro.com wrote:
Structured clone currently doesn't support Functions.
Good. And if I understand it correctly (*), it does make a shallow copy,
ignoring the prototype chain, doesn't it ?
On 14/01/2011, at 15:10, Boris Zbarsky wrote:
On 1/14/11 5:42 AM, Jorge wrote:
Are you sure there's really a maybe for methods ?
Methods' functions have access to (at least) the sender's global context and
contexts can't be shared, how to deal with that if not by prohibiting
methods ?
We
On Fri, Jan 14, 2011 at 9:10 AM, Boris Zbarsky bzbar...@mit.edu wrote:
We might need some ES spec changes/additions to produce methods that would
be safe to pass. I agree that it's not that feasible for now.
Sorry, I've lost track of this part of the discussion. Is functions cloning
needed
Sorry, I've lost track of this part of the discussion. Is functions
cloning needed for non-copying messages, or is this tangental?
It depends on what you want to be able to pass across such non-copying
messages, basically. For simple things, it's not needed.
My impression for zero-copy
On Fri, 14 Jan 2011 12:04:03 +0100, Jorge jo...@jorgechamorro.com wrote:
Structured clone currently doesn't support Functions.
Good. And if I understand it correctly (*), it does make a shallow copy,
ignoring the prototype chain, doesn't it ?
That's correct.
On Thu, 13 Jan 2011 22:15:09 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Do current browsers implement the structured clones already ?
Firefox 4 does, for postMessage to workers (but not yet to other
windows; known bug). I'm not sure about others.
Opera since 10.60 supports structured
On 13/01/2011, at 22:15, Boris Zbarsky wrote:
On 1/13/11 3:19 PM, Jorge wrote:
I think so too for objects composed only of data properties, but what about
methods ? getters ? setters ? and prototypes ?
Maybe. It'd certainly take more work, and might start depending on exactly
how your
On 14/01/2011, at 09:32, Simon Pieters wrote:
On Thu, 13 Jan 2011 22:15:09 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Do current browsers implement the structured clones already ?
Firefox 4 does, for postMessage to workers (but not yet to other windows;
known bug). I'm not sure about
On 13/01/2011, at 22:15, Boris Zbarsky wrote:
On 1/13/11 3:19 PM, Jorge wrote:
On 13/01/2011, at 15:41, Boris Zbarsky wrote:
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of
Boris Zbarsky wrote:
It would be interesting to have an API that allows passing
an imagedata object (not a copy) to a worker. Such an API
would have to make the data disappear on the caller's side.
That could be implemented reasonably efficiently using
shared memory (either directly with
On 1/14/11 5:42 AM, Jorge wrote:
Are you sure there's really a maybe for methods ?
Methods' functions have access to (at least) the sender's global context and
contexts can't be shared, how to deal with that if not by prohibiting methods ?
We might need some ES spec changes/additions to
On 1/14/11 6:15 AM, Jorge wrote:
But in order to measure such short setTimeout()s I needed to know whether +new
Date() had enough resolution (*)
OK, yes.
Cool. What's the right place to start lobbying for it :-) ?
File a bug? ;) (Either on the spec or on browsers, depending on whom
you
I ended up creating a PageWorker object, which is constructed in the page
rather then in a WebWorker. It uses setInterval to repeatedly run a function
in the background to do the image processing directly on the canvas imageD
data. To reduce overhead, each interval runs the function in a small
On Thu, Jan 13, 2011 at 5:08 AM, Berend-Jan Wever skyli...@chromium.org wrote:
I ended up creating a PageWorker object, which is constructed in the page
rather then in a WebWorker. It uses setInterval to repeatedly run a function
in the background to do the image processing directly on the
On 13/01/2011, at 11:35, Glenn Maynard wrote:
On Thu, Jan 13, 2011 at 5:08 AM, Berend-Jan Wever skyli...@chromium.org
wrote:
I ended up creating a PageWorker object, which is constructed in the page
rather then in a WebWorker. It uses setInterval to repeatedly run a function
in the
To preserve shared-nothingness, the passed object (and the object's children)
could be made unreachable (somehow, don't ask me) in the sending context as
soon as passed to the worker. Perhaps other constraints might need to exist,
e.g. perhaps no methods allowed in these objects.
This is a
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of less than
10ms, ever. At this point the only browser that does for repeated
timeouts is Chrome, which allows 4ms. Various
On 13/01/2011, at 14:05, Marijn Haverbeke wrote:
To preserve shared-nothingness, the passed object (and the object's
children) could be made unreachable (somehow, don't ask me) in the sending
context as soon as passed to the worker. Perhaps other constraints might
need to exist, e.g.
But if you could make it unreachable on the sending end then there would be
no need to duplicate it, just to pass a reference to the worker, it would
take about 1 ns.
Yes, but the sender might have gotten this value from anywhere. All
other code using the value will have to know that it is
On 13/01/2011, at 16:27, Marijn Haverbeke wrote:
But if you could make it unreachable on the sending end then there would be
no need to duplicate it, just to pass a reference to the worker, it would
take about 1 ns.
Yes, but the sender might have gotten this value from anywhere. All
On 13/01/2011, at 15:41, Boris Zbarsky wrote:
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of less than 10ms,
ever.
Last time I checked that in 2008, most Mac browsers had a
On 1/13/11 3:19 PM, Jorge wrote:
On 13/01/2011, at 15:41, Boris Zbarsky wrote:
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of less than 10ms,
ever.
Last time I checked that
On Thu, Jan 13, 2011 at 9:41 AM, Boris Zbarsky bzbar...@mit.edu wrote:
In any case, to implement the 4ms thing on Windows Chrome has to have a
dedicated thread polling the multimedia timer, which is a huge PITA in terms
of things like wakeups and battery life... And for what it's worth on my
On 1/13/11 4:37 PM, Glenn Maynard wrote:
- trying to actually get very short, accurate timers, and
- using timers simply to return to the browser, run any pending UI
events, and then immediately start work again with no additional
delay.
The second one is actually really really hard to do with
On Thu, Jan 13, 2011 at 5:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The second one is actually really really hard to do with setTimeout.
Especially if you have UI events that need more than one trip through the
event loop to do their thing.
In simple event systems that's mostly a matter of
On 13/01/2011, at 23:21, Boris Zbarsky wrote:
On 1/13/11 4:37 PM, Glenn Maynard wrote:
I suspect there's something simpler going on here, though--as you
said, copying a 10 MB buffer really should be very quick.
It's really not that quick, actually. First, you have to allocate a new 10MB
On 1/13/11 6:38 PM, Glenn Maynard wrote:
It might be possible to optimize the allocation further, but even
2.5ms is worth optimizing out. If you're trying to maintain 60 FPS
(16.6ms per frame), that's 15% of your total available time (ignoring
concurrency).
Indeed. One more note. My 2.5ms
Hey all,
I read that giving WebWorkers access to the DOM is apparently a bad idea:
http://forums.whatwg.org/viewtopic.php?t=4437
However, the page does not mention why. I'd like to know :)
I ask because I wanted to port an image manipulation script to a WebWorker,
but found out that WebWorkers
Le 07/01/2011 12:24, Berend-Jan Wever a écrit :
Hey all,
I read that giving WebWorkers access to the DOM is apparently a bad idea:
http://forums.whatwg.org/viewtopic.php?t=4437
However, the page does not mention why. I'd like to know :)
When you say the DOM, it could mean two things :
- the
Hi,
On 01/07/2011 12:24 PM, ext Berend-Jan Wever wrote:
I assume you've discussed this before, but couldn't find any record. Please
let me know if there is a document somewhere that explains why WebWorkers
have so little access to browser features.
I did not see the original discussion but
Thanks guys, that makes sense (unfortunately).
So, would it be possible:
1) To give WebWorkers access to the DOM API so they can create their own
elements such as img, canvas, etc...?
2) To create a way to communicate media data between web workers and pages
without serialization, so they can
Le 07/01/2011 14:40, Berend-Jan Wever a écrit :
Thanks guys, that makes sense (unfortunately).
So, would it be possible:
1) To give WebWorkers access to the DOM API so they can create their own
elements such as img, canvas, etc...?
As I mentionned, Ian Hickson's response also covers provoding
As I mentionned, Ian Hickson's response also covers provoding the DOM API
since DOM implementations (besides the document object) aren't thread-safe.
I'm not sure I understand:
- a single WebWorker always runs in only one thread, even though there may
be multiple WebWorkers running on the same
On 1/7/11 10:25 AM, Berend-Jan Wever wrote:
- a single WebWorker always runs in only one thread, even though there may
be multiple WebWorkers running on the same thread, right?
No. For example, in Gecko a given webworker only runs on one thread at
any given moment, but that thread can change
On Fri, Jan 7, 2011 at 3:24 AM, Berend-Jan Wever skyli...@chromium.orgwrote:
I ask because I wanted to port an image manipulation script to a WebWorker,
but found out that WebWorkers have no way to use elements such as canvas
and
img.
fwiw, ImageData can be used in a worker. Many folks have
On Fri, Jan 7, 2011 at 6:22 PM, David Levin le...@chromium.org wrote:
fwiw, ImageData can be used in a worker. Many folks have argued that canvas
isn't that useful in a worker and that the gpu acceleration will make it
less useful (and that most image manipulation would be able to use ImageData
I would recommend that people review this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025254.htmlto
understand the objections previously raised to this idea.
-atw
On Fri, Jan 7, 2011 at 4:08 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jan 7, 2011 at 6:22 PM,
On Fri, Jan 7, 2011 at 8:16 PM, Drew Wilson atwil...@chromium.org wrote:
I would recommend that people review this
thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025254.html
to understand the objections previously raised to this idea.
To comment on one thing in
38 matches
Mail list logo
