- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Dec 2017 04:44:29 +0000
- To: public-css-archive@w3.org
_From @notoriousb1t on July 28, 2016 3:5_ I did not think to check the level 2. Honestly, I'm still trying to get a handle on how the language is written in these specs. I think having it on a separate thread would enforce a clear separation between model updates and view updates and allow the browser to ignore long running update cycles if necessary. By only providing timing information outside of the main thread, it would force all updates based on this information to occur outside of rendering and effectively shrink the amount of work done each time render is called. I think having the update logic execute in a separate context might allow browser vendors to perform additional optimizations on the code itself. I'm making a lot of assumptions though on how the internals of browsers work. I modeled that on what some game engines do. I'm not sure it really applies or that my assumptions are based in reality. I can see how having onsample would provide good secondary effects, but it might be weird to use by itself. That is, creating an empty KeyframeEffect to render to Canvas or audio feels a little tacked on. I think it might be better to have the lower level construct that could in theory be used to create a completely different KeyframeEffect if desired. I'm not saying that to be hyperbolic. I think it would provide a lot of extensibility. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2063#issuecomment-349194064 using your GitHub account
Received on Tuesday, 5 December 2017 04:44:40 UTC