On Sat, Aug 4, 2012 at 11:24 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote: > It doesn't matter if they're bugs (I often see them in conjunction to >> array buffer allocation). >> > Of course it matters. APIs shouldn't be designed based on implementation > bugs It doesn't because those "bugs" have not been fixed the last odd 15 years and with every new vendor repeating them enthusiastically, and the entire WebGL tool ecosystem is growing around those "bugs" to avoid to allocate, ever, during a drawing loop. If you intended to limit the damage, it's too late, done deal. That should've happend 3 years ago. Now it's just dealing with the facts. > Even at the best of times the GC-pauses are no less >> than 90ms, and even if you got it down to 60ms, that's still more than 5 >> frames @80hz. Until you get GC-pauses down to ~5ms or so, any GC use will >> introduce unpleasant stuttering/jittering. And even then it's a close >> call to not miss a frame. >> > 5ms is quite low when the aim is 60Hz updates... but with > incremental/generational GCs 5ms sounds very much possible. > @60hz you're running 16.6ms/frame. 5ms is nearly 1/3 of a frame. If you take up say 12ms to render a frame, then a 5ms pause *will* make you skip a frame. @80hz you take 12.5ms/frame, if your frame needs longer than 7.5ms to produce, again, 5ms *will* skip a frame. 5ms isn't low, it's actually generously big. It's an upper acceptable delay we can work with. Most frames don't take longer than 5ms to produce and render, personally I'm always aiming at keeping the CPU time per frame in the sub millisecond region and see to it the GPU part does not exceed 5ms.
Received on Saturday, 4 August 2012 09:31:47 UTC