Open MatzElectronics opened 7 years ago
Dragging a 20 block group could fire off thousands of onChange events.
A typical defense to this event storm is to set a flag when the objects are selected for movement and then reset the flag after the movement has stopped. Each onChange event handler evaluates the flag to see if it should handle the event or just skip it. Then iterate through the objects and fire each one's onChange() event handler.
Agreed; that's the technique I've applied in other event-driven programming.
IMPORTANT: Ensure there's no way that the flag can be set and not ever cleared (ie: multiple logic exit points of which one or more leaves the flag set accidentally). If there's processing in the same function that must occur after the flag is set, encase that processing block in a try...finally block where the finally clears the flag- that way, any exceptions that could occur don't leave the flag hanging in the set state.
If a project contains a lot of blocks, this becomes a bug.
A number of blocks use onchange handlers - and even the simplest projects fire those off like crazy in blockly, so that code is running near constantly.
Each onchange should either:
This should have the effect of speeding up blockly (preventing it from lagging)