Poll Timer Friday, 3 August 2007

Nicholas Zakas found an unusual use of a poll-timer to work around Internet Explorer's lack of (or useless) resizeEnd event.

Internet Explorer actually does have a onresizeend event, but it is for contentEditable objects, so won't work as you might expect.

I created some activity diagrams to explain what a poll-timer is, Nicholas' variation, and a parameterized variation. Code will obviously be more detailed; diagrams are just for the idea and concept.

Poll Timer

A poll-timer continually polls to see if a condition exists, then fires a signal when it the condition is found.

Resize kicks off the first timer and sets hasResize = true continually.

Once hasResize is found false, the timer won't reset. This type of timer can be implemented with setInterval quite nicely.

Poll-timers are basic and fundamental.

In the resize event, we are checking for absence of a condition: no resize fired within a duration.

The caveat: The final delay time will range from 251ms to as long as 500ms ((2 * DURATION) - 1ms).

Time Resetter (Nicholas' "Downshift" approach)

Nicholas probably saw this and decided to continually reset the timer instead. The trick is to set a timer for a duration after each resize event hits, but first clear the previous timer. Each resize will also clear any preexisting timers.

This diagram calls fireEvent to produce an observable signal, instead of _process( ), as I feel that it is appropriate.

Parameterized Poll Timer

Back to the poll timer.

Since Date is very cheap, and threads are more CPU intensive, then it might be more efficient to set a timeStamp onresize. This would allow us to set a new thread after the old one expired, and only if necessary.

It's more along the lines of a "traditional" poll timer which appeared in the late 90s' DynLayer API, as diagrammed above.

Which one?

Testing is important, and this is merely conjecture. All three should work. The first two are bone simple. The first poll-timer will not fire it's event at a precise moment after the resize end. The parameterized poll-timer will, but is a little more complicated. The parameterized poll-timer should require fewer CPUs (Date is very cheap), but we won't know until it's tested.

I see Nicholas has also developed a testing framework for YUI, (though I have yet to investigate this). For testing user interaction, I feel that Selenium does a thorough job.