[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Resurrecting Update Scheduling



There is no way to guarantee timely callback delivery for normal Web _javascript_, because even in an ideal browser implementation the Web's single-threaded programing model leaves you at the mercy of activities like parsing, layout and the execution of other scripts ("tasks" in HTML5 parlance), including scripts in some other documents.

Thus for normal Web _javascript_, I think an API like the one I proposed is the best you can do ... certainly a big improvement over setTimeout. All you get is a best-effort attempt to fire beforePaint before the browser renders each frame. If the browser is able to composite frames on a different thread from the page's JS thread (highly desirable), and the JS thread can't keep up with the compositing thread (always a possibility), then some beforePaint calls will be skipped, or complete too late, and the JS animation will skip frames. There is no way around this.

To do better than that, we could try to use Web Workers, because they can execute independently of those "main thread" tasks. Workers can't manipulate the DOM or do most of the other things JS animations would like to do. But we could create some kind of API to allow a worker to control a WebGL canvas. Then --- if the browser supports compositing page contents off the main thread --- you could get WebGL canvas animations onto the screen without being vulnerable to main-thread task latency. I see this is a rather advanced feature that most authors would not bother with, and thus relatively low priority.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]