[PE] interface MessageEvent : ProgressEvent
Hi,
While mulling over the usage of PE event, I came up with a suggestion. As the
data attribute of message event delivers structured objects including File Blob
and ArrayBuffer objects, authors might need a primitive way of checking the
progress of message load.
I think the MessageEvent interface derived from ProgressEvent interface would
solve many such use cases. It seems we already have candidates: server-sent
events, web socket, cross-document messaging, channel messaging, web worker.
WDYT?
[Constructor(DOMString type, optional MessageEventInit eventInitDict)]
interface MessageEvent : ProgressEvent {
readonly attribute any data;
readonly attribute DOMString origin;
readonly attribute DOMString lastEventId;
readonly attribute (WindowProxy or MessagePort)? source;
readonly attribute MessagePort[]? ports;
};
Jungkee
-Original Message-
From: Jungkee Song [mailto:jungkee.s...@samsung.com]
Sent: Friday, November 16, 2012 11:53 AM
To: public-webapps@w3.org
Subject: [PE] Start working on Progress Events
Hi all,
I came to start working on Progress Events spec to move it towards REC.
Because the spec is already a CR, I am planning to focus on satisfying the
exit criteria to ship it. Please see inline comments and questions.
Jungkee
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Thursday, November 15, 2012 10:51 PM
On 11/15/12 3:11 AM, ext Jungkee Song wrote:
Hi Art, Charles and Anne,
At this stage, it will be of great help if you give me some comments
on
any issues, concerns, expected actions, etc.
Since the spec is already a CR (with exit criteria
http://www.w3.org/TR/2011/CR-progress-events-20110922/#crec), some
questions ...
* Are there any significant differences between the CR and Anne's WHATWG
spec? If yes, what are they and should they postponed to v.next?
As I've gone through it, there's no significant change. There are only a
few minor ones including term (octets to bytes) and xref (to event
definition) things.
* What is the implementation status of the CR? Are there at least two
independent implementations that can be tested?
This is my question at the moment. Can anyone share implementation data
for this spec?
* Are the tests in the test suite sufficient to test the CR
http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/?
If not, what is the plan to fill the gaps?
I will scope it out.
BTW, I have a relatively strong preference to have this conversation on
public-webapps so please feel free to copy any part of what I say above
to that list.
-Thanks, Art
CfC: Selectors API Level 1 Test Suite; deadline November 23
The RfR for the Selectors API Level 1 test suite passed WebApps' testing group's review (see below), and according to the agreed #Approvalprocess, this now means a group wide review should be done. As such, this is a CfC for this test suite: http://w3c-test.org/webapps/SelectorsAPI/tests/approved/ If you have any comments, please send to public-webapps by November 23. If you review any set of the tests and find no issues, please state that as a reply to this RfR (so we can get a sense of who reviewed what). In the absence of any comments, these tests will be considered Approved. Note: for all practical purposes, I suspect the set of people that will actually review our tests are already subscribed to the testsuite list, thus this extra CfC is unlikely to result in additional review. As such, if no one beats me to it ;-), I will (separately) start a thread about streamlining the testing process a bit (for example remove the separate group wide CfC for a test suite and include the test suite review in the CfC to move a spec from CR to PR). However, let's please not derail this CfC on testing process issues. -Thanks, AB #Approval http://www.w3.org/2008/webapps/wiki/Approval Original Message Subject:Re: RfR: Selectors API Level 1 Test Suite - deadline 14 November Resent-Date:Thu, 15 Nov 2012 16:18:17 + Resent-From:public-webapps-testsu...@w3.org Date: Thu, 15 Nov 2012 17:17:42 +0100 From: ext Charles McCathie Nevile cha...@yandex-team.ru Organization: Yandex To: public-webapps-testsu...@w3.org, Lachlan Hunt lachlan.h...@lachy.id.au, Charles McCathie Nevile cha...@yandex-team.ru On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: This is a request for review of the Selectors API Level 1 test suite. This is a formal resolution that the test suite has passed the review, and is accepted. Although the only review we are aware of is Opera's, there are 5 browsers scoring 97-99% on the tests, and people seem to have checked the tests in practice. cheers Chaals (as co-chair) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more athttp://yandex.com
Re: [PE] interface MessageEvent : ProgressEvent
On Fri, Nov 16, 2012 at 12:48 AM, Jungkee Song jungkee.s...@samsung.com wrote: I think the MessageEvent interface derived from ProgressEvent interface would solve many such use cases. It seems we already have candidates: server-sent events, web socket, cross-document messaging, channel messaging, web worker. WDYT? I'm struggling to see how this makes sense. Sure, we might want progress indication for some of these, but why would you use the MessageEvent interface in that? How does that work? -- http://annevankesteren.nl/
Re: Call for Consensus: CORS to Candidate Recommendation
On 11/15/12 5:31 PM, ext Hill, Brad wrote: I have placed a draft for review at: http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. I support this CfC although I am wondering about the CR exit criteria. Do you expect to re-use the CSP1.0 criteria: [[ The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. ]] My preference is what WebApps has used in other CRs because I think it is clearer that a single implementation is not required to pass every test but that at least two implementations must pass every test. F.ex.: http://www.w3.org/TR/2012/CR-websockets-20120920/#crec -Thanks, AB
Re: Call for Consensus: CORS to Candidate Recommendation
Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document. On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow art.bars...@nokia.comwrote: On 11/15/12 5:31 PM, ext Hill, Brad wrote: I have placed a draft for review at: http://www.w3.org/2011/**webappsec/cors-draft/http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. I support this CfC although I am wondering about the CR exit criteria. Do you expect to re-use the CSP1.0 criteria: [[ The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. ]] My preference is what WebApps has used in other CRs because I think it is clearer that a single implementation is not required to pass every test but that at least two implementations must pass every test. F.ex.: http://www.w3.org/TR/2012/CR-**websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-websockets-20120920/#crec -Thanks, AB
Re: Call for Consensus: CORS to Candidate Recommendation
I object to making such a change. On 11/16/2012 02:32 PM, Glenn Adams wrote: Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document. On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow art.bars...@nokia.comwrote: On 11/15/12 5:31 PM, ext Hill, Brad wrote: I have placed a draft for review at: http://www.w3.org/2011/**webappsec/cors-draft/http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. I support this CfC although I am wondering about the CR exit criteria. Do you expect to re-use the CSP1.0 criteria: [[ The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. ]] My preference is what WebApps has used in other CRs because I think it is clearer that a single implementation is not required to pass every test but that at least two implementations must pass every test. F.ex.: http://www.w3.org/TR/2012/CR-**websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-websockets-20120920/#crec -Thanks, AB
Re: Call for Consensus: CORS to Candidate Recommendation
Cox will file an FO (as a W3C member) if it is not fixed. On Fri, Nov 16, 2012 at 6:51 AM, Ms2ger ms2...@gmail.com wrote: I object to making such a change. On 11/16/2012 02:32 PM, Glenn Adams wrote: Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document. On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 11/15/12 5:31 PM, ext Hill, Brad wrote: I have placed a draft for review at: http://www.w3.org/2011/webappsec/cors-draft/http://www.w3.org/2011/**webappsec/cors-draft/ http://**www.w3.org/2011/webappsec/**cors-draft/http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. I support this CfC although I am wondering about the CR exit criteria. Do you expect to re-use the CSP1.0 criteria: [[ The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. ]] My preference is what WebApps has used in other CRs because I think it is clearer that a single implementation is not required to pass every test but that at least two implementations must pass every test. F.ex.: http://www.w3.org/TR/2012/CR-websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-**websockets-20120920/#crec ht**tp://www.w3.org/TR/2012/CR-**websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-websockets-20120920/#crec -Thanks, AB
[admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]
The W3C's process documents (e.g. #PubRules) define the policies for publications and this issue will be addressed if/when the CR is actually published. WebApps is simply a user of the publication policy. If you want to discuss W3C processes such as PubRules, please use some other list - and not any of WebApps' lists - such as public-w3cprocess #ProcCG. -Thanks, AB #PubRules http://www.w3.org/2005/07/pubrules?uimode=filter #ProcCG http://lists.w3.org/Archives/Public/public-w3process/ On 11/16/12 8:51 AM, ext Ms2ger wrote: I object to making such a change. On 11/16/2012 02:32 PM, Glenn Adams wrote: Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document.
Re: [admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]
Unless I've missed it, I don't believe the #PubRules provides guidelines on what documents are referenced by a spec and whether the reference is normative or non-normative. If I'm wrong, please point out the policy or pubrules text that addresses this issue. Just to be clear, I don't object to including a non-normative reference to the WHATWG variant specification; however, if it is to be a normative reference, I'd like to insist it be the official W3C document that is referenced. On Fri, Nov 16, 2012 at 7:14 AM, Arthur Barstow art.bars...@nokia.comwrote: The W3C's process documents (e.g. #PubRules) define the policies for publications and this issue will be addressed if/when the CR is actually published. WebApps is simply a user of the publication policy. If you want to discuss W3C processes such as PubRules, please use some other list - and not any of WebApps' lists - such as public-w3cprocess #ProcCG. -Thanks, AB #PubRules http://www.w3.org/2005/07/**pubrules?uimode=filterhttp://www.w3.org/2005/07/pubrules?uimode=filter #ProcCG http://lists.w3.org/Archives/**Public/public-w3process/http://lists.w3.org/Archives/Public/public-w3process/ On 11/16/12 8:51 AM, ext Ms2ger wrote: I object to making such a change. On 11/16/2012 02:32 PM, Glenn Adams wrote: Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document.
random numbers API
Motivation: Web Applications enter the arena of interactive content creation/consumption (games, productivity software, etc.). A good PRNG would be desirable in many situations. Web Applications that desire to use random numbers have a 4 problems with the existing Math.random function. 1) The implementation is not high quality in that the generated random numbers tend to be statistically poor compared to other higher quality PRNGs. 2) The API does not support seeding whereas the same sequence of random numbers can be generated twice if so desired. 3) It is based on floating points which due to machine differences even in the presence of seeding could generate different numbers. 4) Alternative implementations in JS suffer even in the presence of sophisticated JITing VMs from the fact that mathematics is done in doubles (in the case of addition, subtraction, division and multiplication) and by converting double - int - double (in the case of bitshifts and modulo division). This makes it both harder to implement a reliable PRNG and it makes it slow. I would propose an alternative native code random number API that has the following characteristic: - The returned value is based on integers ranging from 0 up to a specified limit. - It is initializable with a seed - It makes a guarantee that no matter on what machine the random number is generated, that the sequence of random numbers to the same seed is identical. - It selects a suitable PRNG algorithm to that end that satisfies a high standard of statistical qualities of PRNGs and exhibits good runtime performance. It could look something like this for example: var prng = new PRNG(seed); var x = prng.random(limit);
Re: random numbers API
On Fri, Nov 16, 2012 at 7:13 AM, Florian Bösch pya...@gmail.com wrote: Motivation: Web Applications enter the arena of interactive content creation/consumption (games, productivity software, etc.). A good PRNG would be desirable in many situations. Did you discuss this with TC39? -- http://annevankesteren.nl/
Re: random numbers API
The W3C Web Cryptography working group [1] has a draft that seems to include a method to generate cryptographically random values [2]. I'm not sure how well that relates to what your use case requires but it might be worth looking at. regards, Frederick Frederick Hirsch Nokia [1] http://www.w3.org/2012/webcrypto/ [2] http://www.w3.org/TR/WebCryptoAPI/#Crypto-method-getRandomValues On Nov 16, 2012, at 10:13 AM, ext Florian Bösch wrote: Motivation: Web Applications enter the arena of interactive content creation/consumption (games, productivity software, etc.). A good PRNG would be desirable in many situations. Web Applications that desire to use random numbers have a 4 problems with the existing Math.random function. 1) The implementation is not high quality in that the generated random numbers tend to be statistically poor compared to other higher quality PRNGs. 2) The API does not support seeding whereas the same sequence of random numbers can be generated twice if so desired. 3) It is based on floating points which due to machine differences even in the presence of seeding could generate different numbers. 4) Alternative implementations in JS suffer even in the presence of sophisticated JITing VMs from the fact that mathematics is done in doubles (in the case of addition, subtraction, division and multiplication) and by converting double - int - double (in the case of bitshifts and modulo division). This makes it both harder to implement a reliable PRNG and it makes it slow. I would propose an alternative native code random number API that has the following characteristic: - The returned value is based on integers ranging from 0 up to a specified limit. - It is initializable with a seed - It makes a guarantee that no matter on what machine the random number is generated, that the sequence of random numbers to the same seed is identical. - It selects a suitable PRNG algorithm to that end that satisfies a high standard of statistical qualities of PRNGs and exhibits good runtime performance. It could look something like this for example: var prng = new PRNG(seed); var x = prng.random(limit);
Re: random numbers API
On Fri, Nov 16, 2012 at 4:22 PM, Anne van Kesteren ann...@annevk.nl wrote: Did you discuss this with TC39? I did not, sorry if this is the wrong place for it.
Re: random numbers API
On Fri, Nov 16, 2012 at 4:24 PM, frederick.hir...@nokia.com wrote: The W3C Web Cryptography working group [1] has a draft that seems to include a method to generate cryptographically random values [2]. It does include a random number generator. However it does not include seeding and consequentially no guarantees about the algorithm and repeatability.
Re: random numbers API
Le 16/11/2012 16:30, Florian Bösch a écrit : On Fri, Nov 16, 2012 at 4:24 PM, frederick.hir...@nokia.com mailto:frederick.hir...@nokia.com wrote: The W3C Web Cryptography working group [1] has a draft that seems to include a method to generate cryptographically random values [2]. It does include a random number generator. However it does not include seeding and consequentially no guarantees about the algorithm and repeatability. That'd be a nonsense to add seeding in my opinion. If you want security, you don't want to take the risk of people seeding and loose all security property. If it's for debugging purposes, the seeding should be part of a devtool, not of the web-facing API. David
Re: random numbers API
On Fri, Nov 16, 2012 at 5:20 PM, David Bruant bruan...@gmail.com wrote: That'd be a nonsense to add seeding in my opinion. If you want security, you don't want to take the risk of people seeding and loose all security property. If it's for debugging purposes, the seeding should be part of a devtool, not of the web-facing API. I agree that in the crypographic context seeding might not make sense (or even guarantees about repeatability). The purpose of the proposal of a fast, reliable, statistically sound, repeatable, seedable PRNG in JS however is not to do cryptography. It would be to be able to perform procedural computation repeatably regardless of machine, VM, optimization and vendor differences. An example: Say you wanted to do a procedural universe consisting of 1 million stars. At 3 cartesian coordinates per star and at each component having 8 bytes, you'd get 22MB of data. If you want to share this galaxy with anybody you'll have to pass them this 22mb blob. If you want multiple people in the same galaxy, you have to pass them that blob. It takes about 0.7 seconds in C to generate 3 million statistically sound random numbers for longs. The seed to the galaxy is just a few bytes. So why do we have to transfer 22mb for the web?
Re: random numbers API
On 11/16/12 7:13 AM, Florian Bösch wrote: 4) Alternative implementations in JS suffer even in the presence of sophisticated JITing VMs from the fact that mathematics is done in doubles (in the case of addition, subtraction, division and multiplication) and by converting double - int - double (in the case of bitshifts and modulo division). This makes it both harder to implement a reliable PRNG and it makes it slow. I would be interested in some specific data here. Do you have an example of a PRNG that is actually being slow? -Boris
Re: random numbers API
Le 16/11/2012 17:35, Florian Bösch a écrit : On Fri, Nov 16, 2012 at 5:20 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: That'd be a nonsense to add seeding in my opinion. If you want security, you don't want to take the risk of people seeding and loose all security property. If it's for debugging purposes, the seeding should be part of a devtool, not of the web-facing API. I agree that in the crypographic context seeding might not make sense (or even guarantees about repeatability). The purpose of the proposal of a fast, reliable, statistically sound, repeatable, seedable PRNG in JS however is not to do cryptography. It would be to be able to perform procedural computation repeatably regardless of machine, VM, optimization and vendor differences. An example: Say you wanted to do a procedural universe consisting of 1 million stars. At 3 cartesian coordinates per star and at each component having 8 bytes, you'd get 22MB of data. If you want to share this galaxy with anybody you'll have to pass them this 22mb blob. If you want multiple people in the same galaxy, you have to pass them that blob. If you want repeatable, you actually don't want random (as your title suggests) but PRNG very specifically (pseudo being themost important part). In that case, I feel writing your own PRNG will be almost as fast as a native one with nowadays crazy JIT. Just write an algorithm that you're satisfied and pass around the algo and any parametrization you want. I feel it would solve your use case. It takes about 0.7 seconds in C to generate 3 million statistically sound random numbers for longs. Do you have measurements of how much the same algo takes in JS? David
Re: random numbers API
I'll see that I can come up with a test suite that verifies statistical and runtime behavior of an array of algorithms implemented in JS, it'll probably take a while. On Fri, Nov 16, 2012 at 6:02 PM, David Bruant bruan...@gmail.com wrote: Le 16/11/2012 17:35, Florian Bösch a écrit : On Fri, Nov 16, 2012 at 5:20 PM, David Bruant bruan...@gmail.com wrote: That'd be a nonsense to add seeding in my opinion. If you want security, you don't want to take the risk of people seeding and loose all security property. If it's for debugging purposes, the seeding should be part of a devtool, not of the web-facing API. I agree that in the crypographic context seeding might not make sense (or even guarantees about repeatability). The purpose of the proposal of a fast, reliable, statistically sound, repeatable, seedable PRNG in JS however is not to do cryptography. It would be to be able to perform procedural computation repeatably regardless of machine, VM, optimization and vendor differences. An example: Say you wanted to do a procedural universe consisting of 1 million stars. At 3 cartesian coordinates per star and at each component having 8 bytes, you'd get 22MB of data. If you want to share this galaxy with anybody you'll have to pass them this 22mb blob. If you want multiple people in the same galaxy, you have to pass them that blob. If you want repeatable, you actually don't want random (as your title suggests) but PRNG very specifically (pseudo being themost important part). In that case, I feel writing your own PRNG will be almost as fast as a native one with nowadays crazy JIT. Just write an algorithm that you're satisfied and pass around the algo and any parametrization you want. I feel it would solve your use case. It takes about 0.7 seconds in C to generate 3 million statistically sound random numbers for longs. Do you have measurements of how much the same algo takes in JS? David
Re: random numbers API
On Fri, Nov 16, 2012 at 9:20 AM, Florian Bösch pya...@gmail.com wrote: I'll see that I can come up with a test suite that verifies statistical and runtime behavior of an array of algorithms implemented in JS, it'll probably take a while. Thank you! As a side benefit, having a library of tested PRNGs implemented in JS with a good license would be quite handy. On Fri, Nov 16, 2012 at 6:02 PM, David Bruant bruan...@gmail.com wrote: Le 16/11/2012 17:35, Florian Bösch a écrit : On Fri, Nov 16, 2012 at 5:20 PM, David Bruant bruan...@gmail.com wrote: That'd be a nonsense to add seeding in my opinion. If you want security, you don't want to take the risk of people seeding and loose all security property. If it's for debugging purposes, the seeding should be part of a devtool, not of the web-facing API. I agree that in the crypographic context seeding might not make sense (or even guarantees about repeatability). The purpose of the proposal of a fast, reliable, statistically sound, repeatable, seedable PRNG in JS however is not to do cryptography. It would be to be able to perform procedural computation repeatably regardless of machine, VM, optimization and vendor differences. An example: Say you wanted to do a procedural universe consisting of 1 million stars. At 3 cartesian coordinates per star and at each component having 8 bytes, you'd get 22MB of data. If you want to share this galaxy with anybody you'll have to pass them this 22mb blob. If you want multiple people in the same galaxy, you have to pass them that blob. If you want repeatable, you actually don't want random (as your title suggests) but PRNG very specifically (pseudo being themost important part). In that case, I feel writing your own PRNG will be almost as fast as a native one with nowadays crazy JIT. Just write an algorithm that you're satisfied and pass around the algo and any parametrization you want. I feel it would solve your use case. It takes about 0.7 seconds in C to generate 3 million statistically sound random numbers for longs. Do you have measurements of how much the same algo takes in JS? David
Re: random numbers API
Le 16/11/2012 18:20, Florian Bösch a écrit : I'll see that I can come up with a test suite that verifies statistical and runtime behavior of an array of algorithms implemented in JS, it'll probably take a while. I don't think you need to go through such lengths. If you do have the galaxy use case, implement it with the same C algorithm you used to get the 0.7s measurement and see if JS perf is actually a problem. David
Re: exposing CANVAS or something like it to Web Workers
On Mon, 14 May 2012, Gregg Tavares (�~K�) wrote: I'd like to work on exposing something like CANVAS to web workers. Ideally how over it works I'd like to be able to *) get a 2d context in a web worker *) get a WebGL context in a web worker *) download images in a web worker and the images with both 2d contexts and WebGL contexts I've now specced something like this; for details, see: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: exposing CANVAS or something like it to Web Workers
On Nov 16, 2012, at 1:50 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 May 2012, Gregg Tavares (�~K�) wrote: I'd like to work on exposing something like CANVAS to web workers. Ideally how over it works I'd like to be able to *) get a 2d context in a web worker *) get a WebGL context in a web worker *) download images in a web worker and the images with both 2d contexts and WebGL contexts I've now specced something like this; for details, see: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html Seems like we might use requestAnimationFrame in the main thread to postMessage to the worker as an alternative to using setInterval in workers for repaints. -Charles
Re: exposing CANVAS or something like it to Web Workers
On Fri, 16 Nov 2012, Charles Pritchard wrote: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html Seems like we might use requestAnimationFrame in the main thread to postMessage to the worker as an alternative to using setInterval in workers for repaints. The idea in due course is to just expose rAF in workers. Please do read the e-mail above, which actually mentions that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
