requestAnimationFrame based rendering

Performance
5

I made a small tweak to the snippet above to also add perf measures, so we can see whats happening in a trace:

Ember.run.backburner._platform.setTimeout = function(method, wait) {
  var start = window.performance.now();
  var i = Math.random();
  performance.mark('start' + i);
  var wrapped = function() {
    performance.mark('stop' + i);
    performance.measure('timeout of ' + wait, 'start' + i, 'stop' + i);
    var duration = window.performance.now() - start;
    if ((duration - wait) > 10) {
      console.log("setTimeout unexpectedly delayed. Expecting: " + wait + "ms actual: " + duration + "ms");
    }
    method();
  }
  return setTimeout(wrapped, wait);
}

For example, this section looks very reasonable:

image
image1063×319 29.4 KB
https://discuss.emberjs.com/uploads/short-url/laVpcvYKw6KeIYYzXLrR7SENEOv.png

And so does this segment:

image
image1073×232 17 KB
https://discuss.emberjs.com/uploads/short-url/1b4wfzpFZxxdZHqfRts1AkxmyCT.png

(sorry, but got this when posting: “Sorry, new users can only put one image in a post.”)

But then there are also timer delays like this, which I don’t really understand:

image
image1058×257 19.2 KB

So yeah I think I can agree when @sam said:

once you throttle CPU and run the profiler you can actually see the computer sitting there doing nothing on lots of these “extra” delays, Something is not quite right with the Chrome algorithm

2 Likes