[squeak-dev] computers too fast these days?

Chris Muller asqueaker at gmail.com
Wed Aug 21 15:35:37 UTC 2013


Tobias, when we use reasons like "should" and "does not belong", I
understand you're saying how it feels in your guts, but unfortunately
it does not provide a basis for us to engage in logical debate and
decision making.

You raise a good point about it possibly being covered by another
Morph.  No answer for that other than the user could instruct the
morph they're about to flash (its parent-most Morph under the World)
to comeToFront first..

I think most of us agree we don't normally want to "block" the UI and
doing so certainly goes against Morphic principles.  But this is just
#flash so -- 1) the blockage is for one "frame", what are we going to
miss?  2) the blockage reinforces it's function -- because what if
there are 100 Morphs already on the screen (perhaps as part of the
Game loop you mentioned), which all have a flashing-effect as part of
their stepping.  It would be difficult to see the 101st one I'm
flashing deliberately.  So, one could argue, blocking the UI pausing
briefly is actually *by design* for the flash function.  Finally, 3) a
Delay is simply TSTTCPW.  Sure we could introduce a complicated
stepping / alarms, whatever, but at the end of the day, what have we
gained by that?

Right now #flash doesn't really work at all so our choices are to 1)
leave it broken, 2) put in a brief Delay, or 3) something else.
Keeping in mind, until someone DOES the "something else" it's
essentially the same as (1).


On Wed, Aug 21, 2013 at 9:05 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 19.08.2013 um 20:53 schrieb Chris Muller <asqueaker at 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
>
> iEYEARECAAYFAlIUyUYACgkQcPVIrP6PLKsOCgCdFoODDTV0QuZDr+xesVResYeb
> K7gAniOwZnUwUB26w0QEkJ9xlSjT9wWV
> =5Nkq
> -----END PGP SIGNATURE-----
>


More information about the Squeak-dev mailing list