20:09:00 RRSAgent has joined #parallel 20:09:00 logging to http://www.w3.org/2014/10/29-parallel-irc 20:09:44 zcorpan has joined #parallel 20:10:11 q? 20:10:23 Zakim has joined #parallel 20:10:36 q? 20:10:57 RRSAgent: make logs public 20:17:08 a12u has joined #parallel 20:18:18 aaa has joined #parallel 20:19:36 aaa has left #parallel 20:20:21 aizu has joined #parallel 20:20:50 tobint has joined #parallel 20:20:53 tripu has joined #parallel 20:29:29 hober has joined #parallel 20:31:35 annette_g has joined #parallel 20:31:58 ujvari has joined #parallel 20:32:17 kinjim_ has joined #parallel 20:32:29 Cyril has joined #parallel 20:32:49 scribeNick: Cyril 20:32:50 Travis: (travis explaining the rendering pipeline) 20:32:58 ... webworker introduces a new pipeline 20:33:07 ... that does not communicate with the main pipeline 20:34:16 Cyril_ has joined #parallel 20:34:26 philcohen has joined #parallel 20:34:48 ... the spec was enhanced to improve the transfer of large data 20:34:57 ... but transferring arrays 20:34:58 s/but/by/ 20:35:10 ... once the data is transfered, it cannot be worked on anymore by the initial thread 20:35:29 ... sharedworkers have been introduced but have a different lifetime 20:35:51 ... there is a need for worker to persist 20:36:14 ... more recently we have serviceworkers: short lived entity to handle low level communications 20:36:21 ... limited set of utilities 20:36:33 ... still does no't have access to the main document 20:36:42 ... may not have an associated UI at all 20:37:02 alex: there is a new type of worker called audioworker 20:37:14 xxx; there is also a new UIWorker 20:37:26 ... to explain threaded animations and scrolling 20:37:47 alex: conceptualy that's the thing owning the rendering box 20:38:03 rbyers has joined #parallel 20:38:09 rniwa has joined #parallel 20:38:30 Travis: the subsystem for rendering video is not blocked by the main thread 20:38:41 ... there are other subsystems that do run too 20:39:09 ... IE has been working on the round trip time to come back to the main thread more quiclky 20:39:21 ... in IE rendering is another thread 20:39:36 apple: rendering means painting 20:39:52 ... and composition ? 20:39:56 Travis: yes 20:40:07 ... in IE they can run in parallel 20:40:21 s/apple/rniwa/ 20:41:03 Travis: are there reasons why we should be added more parallel forms of environement 20:41:09 ... not so isolated as workers ? 20:41:33 ... some people would like to do some DOM operatiosn in workers 20:42:11 joe: the problem in audio is that we do in JS things similar to what browsers do under the hood 20:42:24 ... it'd be great to do this in workers 20:42:32 ... but we want the DOM to be exposed to workers 20:42:48 ... we want to access the data model accesses by other objectis in the pipeline 20:43:09 Travis: would a javascript shared object be useful 20:43:13 joe: yes 20:43:54 ... I have a rough idea of the problem space 20:44:03 ... I don't know if workers can satisfy this case 20:44:09 ? 20:44:14 q? 20:44:50 jacob: under the cover, we have a separate object model and we exchange messages between workers 20:45:02 ... the next step is shared memory model 20:45:06 kurosawa has joined #parallel 20:45:10 alex: we have a series of problems related 20:45:26 ... in a shared memory model world (e.g. typed arrays) 20:45:39 ... in dynamic fluid simulator we had problems 20:45:59 ... we find that there is high cost in synchronisation 20:46:06 ... game developpers told us to 20:46:13 s/us to/us too/ 20:46:26 ... imagine sending a subset of a bytearray 20:46:30 ... but locks are bad 20:47:12 ... for service workers we have a new storage class like cache 20:47:21 but we want operations to be atomic 20:47:33 ... but we are concerned how users will interact with that 20:48:13 Travis: the question is: give some access to the DOM but 20:48:31 ... someone moves an elemetn in the tree while it's been accessed by someone eles 20:48:53 ... maybe a solution would be to declare an intention to do some modifications 20:49:06 ... the platform could snap a (ro, rw) view 20:49:11 ... similar to indexeddb 20:49:16 ... to have a stable snapshot 20:49:23 rniwa: like a transaction? 20:49:31 Travis: yes 20:49:42 Travis: that sounds fantastic for readers 20:49:52 ... traversing and finding stuff 20:50:05 ... the problem is writing 20:50:11 ???: same as databases 20:50:30 alex: we discussed a lock ordering primitive 20:50:42 ... registering a lock that can be released in the same order 20:50:46 ... to avoid dead locks 20:50:57 ... that would open cross tick transactions 20:51:07 ... I don't know if this gets out of the main problem 20:51:33 ???: travis, what about decomposing the frame in sub parts 20:51:52 ... parallelism through decomposition ? 20:52:01 annette_g: splitting by layers 20:52:16 s/???/rbyers/ 20:52:22 Travis: in canvas, you can create separate canvases 20:52:33 alex: maybe a worker for canvas 20:52:45 jacob: that is easy for canvas 20:52:58 ... it gets challenging for other approaches, like layers 20:53:08 ... developpers don't understand what creates a layer 20:53:17 kinjim_ has joined #parallel 20:53:25 ... the DOM and layout don't correspond 20:53:52 rniwa: you can't separate a layer because it affects other layers 20:54:19 tobint: a layer needs to be synced with other layers 20:54:20 https://html.spec.whatwg.org/multipage/scripting.html#proxying-canvases-to-workers 20:54:27 zcorpan: canvas can be controlled by workers 20:54:40 ???: is it implemented 20:54:46 zcorpan: I don't know 20:55:11 Travis: svg can be also interesting if it is used in an image 20:55:24 ... the processing could be handled by the worker 20:55:29 rniwa: if the width and height is fixed 20:55:42 Travis: potentially depends on who controls the size 20:56:37 kinjim__ has joined #parallel 20:57:00 philcohen has joined #parallel 20:57:02 alex: you could imagine a master processes spawning many threads 20:57:17 ... with regular workers in different pipes (audio, ui) 20:57:34 ... and you need to provide controls to say to which OS threads will use them 20:57:42 ... audio is interesting 20:58:00 jacob: we need to identify locks in the diagram 20:58:11 ... i worry if we have too many types of workers 20:58:22 ... and how they correspond to threads 20:58:45 Travis: what about the shared memory concept 20:58:52 joe: back to my use case 20:59:00 ... today because of the lack of shared memory 20:59:10 ... the only way to do it is to use messages 20:59:20 ... I'm concerned that we have a lot of traffic 20:59:24 ... because of hte lack of locks 20:59:45 ... read-only would help already, without the overhead 20:59:49 alex: what format of data 20:59:54 joe: JSON 21:00:09 kinjim has joined #parallel 21:00:11 alex: we don't have a serialization of JS objects 21:00:26 ... because of prototypes 21:00:36 joe: without prototypes, would hte problem be more tractable 21:01:03 alex: the simple way would be to express your data in byte array 21:01:29 joe: we need to write our own library aware of mutations 21:01:40 ... that can be done in JS, that's cumbersome 21:01:51 alex: JS value types could help 21:02:02 rniwa: do you want to have actual locks in your app 21:02:11 ... and do the manual locking/unlocking 21:02:17 joe: I don't want to do that 21:02:28 Travis: I want the writing atomic 21:03:02 ... willing to have undefined because of timing conditions 21:05:35 rniwa: you might need atomic swap 21:05:54 .. if read and write are not atomic, you may have problems 21:06:08 ... you may not know if your write was successful 21:07:40 Cyril: what about scoped JS 21:07:43 Travis: that sounds interesting 21:08:21 alex: what about changing the prototype in this case 21:08:36 zcorpan: that's like iframe 21:08:52 alex: you cannot if it is cross-origin 21:10:05 zcorpan: are cross origin iframes run in parallel? 21:10:05 Travis: IE does not 21:10:05 ... we are searching for obvious boundaries 21:10:06 zcorpan: if the parallelized iframes is useful for apps 21:10:06 ... owuld it make sense to provide an opt-in mechanism 21:10:15 dom: this may be useful for web components 21:11:27 Travis: maybe transferring documents could be useful 21:11:29 song has joined #parallel 21:12:04 ???: yes, creating a document in a worker, doing some rendering, measurements and then transferring it 21:13:54 s/provide an opt-in mechanism/provide an opt-in mechanism for same-origin/ 21:14:09 Cyril has joined #parallel 21:14:23 travis: is improved parallelism necessary: yes 21:14:33 ... lots of gaps in existing technologies 21:15:26 Cyril has joined #parallel 21:16:23 ... new kinds of workers 21:16:34 Cyril_ has joined #parallel 21:16:43 ... research in JS to support shared memory 21:16:58 ... finding ways to put things in new workers. 21:35:39 rbyers has left #parallel 21:56:36 Cyril has joined #parallel 22:35:32 Cyril has joined #parallel