- From: Boris Zbarsky via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jun 2016 18:33:33 +0000
- To: public-houdini-archive@w3.org
A long running paint worklet is different from a main JS script in one simple way: putting up a slow script thing does NOT require reentry into main JS script (and in fact, not reentering it is preferable). But you _do_ want to keep painting the page instead of having stuff freeze up, for better UX. And that's what all this is about, really: this spec is trying to dictate UX, which is not really what it should be doing. > We don't want to force implementors to explicitly run the paint worklet on a separate thread, just so that they can kill it if there is a while(1); loop. Why would that require having it on a separate thread? It totally doesn't, at least in the implemetations I'm familiar with. For example, the Firefox slow script dialog has a "kill script" option right there, which does just that. For a slow paint function we would just do that without bothering to ask the user and treat it just like we would treat the paint function throwing an exception. Which would produce an invalid image, per text already in the spec. -- GitHub Notification of comment by bzbarsky Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/236#issuecomment-227836442 using your GitHub account
Received on Wednesday, 22 June 2016 18:33:36 UTC