Fix bug 382. Simplify resizing by not recreating everything from scratch. This makes...
authorRobert Konigsberg <konigsberg@google.com>
Sat, 2 Mar 2013 21:15:41 +0000 (16:15 -0500)
committerRobert Konigsberg <konigsberg@google.com>
Sat, 2 Mar 2013 21:37:41 +0000 (16:37 -0500)
commitaeca29acb29d62c57663786dd8b9eba7fcc959a6
tree23d138aa96026fc4e6baeb597aeda12f6f6fe806
parent870190b5b5ad4e2ee930d14ac1c5d0e2be6f8fe0
Fix bug 382. Simplify resizing by not recreating everything from scratch. This makes it simpler to deal with i328, since we don't have to worry about unremoved event handlers.

Since we're not building everything from scratch, we have to make sure the clipping area is set correctly. Although there's a resetClip method in the HTML5 spec, it's too new. But, man, if we had it things would be great. So instead there's a conditional restore (no restore on the first operation) and a save, for the subsequent restore.

Almost all tests pass, but the ones that test save/restore balances are unsurprisingly broken, as there's one additional save. This can be addressed with calls to g.destroy prior to the assertion, or make a special assertion that verifies there's one more context save than restore.

This has an additional benefit of being slightly faster. Using /Users/konigsberg/git/kberg-dygraphs/tests/resize.html and the following snippet

var start = new Date().getTime();
for (var idx = 0; idx < 500; idx++) {
    g.resize(100 + idx, 100 + idx);
}
console.log(new Date().getTime() - start);

I frequently saw a difference of about 200ms (2200-range to 2400-range.) How much of that was drawing a mildly complex image? Who knows?

I also did some minor refactoring with regards to events, and event method names to make things easier to track.

There may be a need for a plug-in event for resizing.
dygraph-utils.js
dygraph.js
extras/unzoom.js
plugins/annotations.js
plugins/range-selector.js