-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 19.08.2013 um 20:53 schrieb Chris Muller asqueaker@gmail.com:
I agree with Bob. 100ms only "slows the UI" down to 10 fps for one "frame." By holding everything else static for that one frame, it reinforces the purpose of flash which is to draw the users attention to that one particular morph.
what if the morph is behind another one? Then the UI goes halt for no apparent reason.
In an extremely busy-animated UI, flash might otherwise not fulfill this goal as effectively.
Animation in morphic is normally handled by implementing #step and #stepTime, not alarms. But #flash is not animation, it's like #beep. It's a user poke, not program output.
Which should be non-blocking nonetheless. When my terminal on OSX flashes (visual bell, the exact same concept), it does not do it in a blocking fashion, all other UI stuff continues to work. Again, I am strongly opposed agains any change that introduces blocking into the UI. It just does not belong there. Modal dialogs that also draw the attention to the current screen activity also do not block the UI. The same way, a #beep should not block the UI. Think of a typical Game loop that adjusts its calculation based on the measured fps (for example by adjusting stepping time). This would introduce unwanted jumps in that game loop just because some morph somewhere flashed.
I agree that a #flash like a #beep should be always noticeable[1] but I think a Delay for: whatevernumber is the wrong way.
I just tested Bobs fix and then did the following: Open a browser, focus the Protocol pane, start typing like crazy (say 50 character in very short time). The effect was that my UI was blocked for more than thee (3) seconds. This should really not happen.
Best -Tobias
[1] side note: there should be a preference to turn a #beep into a #flash automatically, akin to a terminal’s infamous visual bell, and probably vice versa.