2

I have a page where a large number of DOM elements are animated. This mostly works on modern hardware and software, but I worry that it may be too sluggish on older computers with slow javascript interpreters.

What I would like to do is to get some information about the performance of the DOM and disable some of the animations if this is under a certain threshold. A naif way could be by adding 10000 or so transparent elements and removing them and measuring the time needed. Before going to implement this, I would like to know whether something of this kind, maybe more refined, already exists.

Do you know of any tool that gives a resonable measure of the DOM performance?

Andrea
  • 20,253
  • 23
  • 114
  • 183
  • "DOM Performance" -> Using DOM methods (`document.getElementById, appendChild, ...`) or performance of your JavaScript code? Keep in mind: The most important part of a page is the content, *not* thousands of unnecessary animations. – Rob W Oct 27 '11 at 08:14
  • Well, the content of this particular page is a big animation :-) – Andrea Oct 27 '11 at 08:21
  • And yes, I mean DOM performance. I have to move a lot of DOM elements around, so this is what I am interested in. – Andrea Oct 27 '11 at 08:22
  • Use http://jsperf.com/, as mentioned at my answer, and copy-paste your HTML tree to it. Then, create a test case which is a good sample of your code, which moves elements through your tree. If necessary, define *teardown* code. – Rob W Oct 27 '11 at 08:25
  • The code has to execute before the animation starts. I cannot use the animation itself to test the browser performance. I could hide the elements, but this would affect the test, because the browser would not have to load them. I have a simple test which adds and removes 10000 transparent gif absolutely positioned at random spots on the page, and it works decently. I was wondering whether something better already exists. – Andrea Oct 27 '11 at 08:45

2 Answers2

1

If you measure the actual frame rate of your animation, you can compare that to the frame rate you are trying to animate at. If the actual frame rate is significantly lower, then you can draw at a slower rate, or draw less. There's a description of Google doing that in this answer.

Community
  • 1
  • 1
Douglas
  • 36,802
  • 9
  • 76
  • 89
  • The problem is, there is no setInterval in my case, hence no concept of frame rate. I just udpate the position of some DOM elements as the mouse moves - that is, in a mousemove callback. A posteriori, I realize that doing so is not optimal, and polling the mouse position every few milliseconds would have been better, and would have allowed me to benchmark the frame rate on the fly, but it is now too late to change this, Thank you anyway for your suggestion. – Andrea Dec 23 '11 at 19:53
  • I've found that (at least in the past) Firefox would fire many more than expected mouse move events, which cause animations to stutter if I updated the dom too often. The fix there was to only act on the event if the mouse event's x and y had actually changed. You could do something similar, such as only process the event if it is x milliseconds [since the last](http://documentcloud.github.com/underscore/#throttle), though if you have multiple mouse move handlers I can see that getting complicated quickly... – Douglas Dec 25 '11 at 22:45
0

You can implement a prototype and profile it in a WebKit-based browser (Chrome/Safari) using Chrome Developer Tools or Web Inspector (the Profiles panel). This will give you an insight into what's actually slowing down your app: the JavaScript code or the WebKit internals.

Alexander Pavlov
  • 31,598
  • 5
  • 67
  • 93
  • My app is not slow on today's browsers. It just is on older ones. Maybe I was not clear, but I am *not* trying to benchmark my code. I am trying to judge whether my code is executing on a slow browser and opt out some features in that case. That has to be done on the fly, before starting the animation. – Andrea Dec 23 '11 at 19:47
  • Oh, well, that is _exactly_ benchmarking your code on the user's browser :) But from you comment to the next answer I'm seeing that what you actually need is the mouse event handler throttling, which is usually implemented by running your actual handler code a'la `if (!this._timer) this._timer = setTimeout(func, )` and calling `this._timer = null;` (or `delete this._timer`) in the func() body. – Alexander Pavlov Dec 26 '11 at 08:32