No--you have it backwards. The problem comes from delayed clicks, it won't be cured by delaying clicks. You click the spot you want and something more loads causing the control to move before the click is processed.
I'm not sure how to do it but the clicks need to be processed against the state of the display when the click was done rather than against the state when the click was processed. The only way to do this that comes to mind is to snapshot the hot zones on the screen before doing anything that will disrupt the screen and any click received during or within 300ms (configurable, I'm figuring a minimum reaction time) after the screen update should be processed against that map, not against the current state.
It still will be a timing game.
What if I want to click on the new object in 300 ms time period?
I need to wait 300 ms to do so, this is a flow issue.
If 1 billion current MS Windows users would make daily 1000 UI operations, but each time wait 100 ms for UI animations, the collective wasted time on the animations would be 3000 years of collective wasted time.
Fortunately most are just watching movies and shopping online, so not much collective _productive_ time is wasted ;)
I'm not sure how to do it but the clicks need to be processed against the state of the display when the click was done rather than against the state when the click was processed. The only way to do this that comes to mind is to snapshot the hot zones on the screen before doing anything that will disrupt the screen and any click received during or within 300ms (configurable, I'm figuring a minimum reaction time) after the screen update should be processed against that map, not against the current state.