[squeak-dev] computers too fast these days?

Bob Arning arning315 at comcast.net
Wed Aug 21 15:03:01 UTC 2013


On 8/21/13 10:14 AM, Tobias Pape wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 21.08.2013 um 16:05 schrieb Tobias Pape <Das.Linux at gmx.de>:
> Am 19.08.2013 um 20:53 schrieb Chris Muller <asqueaker at gmail.com>:
> […]
>    Think of a typical Game loop that adjusts its calculation based
>
> would introduce unwanted jumps in that game loop just because some
> morph somewhere flashed.
I'm not sure how timing-critical games relate to the current users of 
#flash. I can't really get my head around playing such a game *while* 
typing 50 characters really fast in a browser pane. The delay, 
introduced in direct response to user input, is probably a good bit less 
that that for searching all methods with "foo" in their source or adding 
an instance variable to a class with 50 subclasses. If you are 
programming while gaming, both may suffer. Note that none of this 
prevents someone from creating a gentler #flashEverSoDiscreetly for 
special cases where you don't want to cause offense.
>
> 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.
One thing that helps is if senders of #flash like this one also flushed 
any pending input events. If you are really that fast a typist and do

     <cmd-f>foo<return>bar

and "foo" is not found, then "bar" gets entered at the previous 
selection, not replacing "foo" as desired. #flash means the last thing 
you did didn't work and there's a strong possibility any stuff you 
already types in is wrong.
>
> Interestingly, repeatedly flashing a UserDialogBoxMorph does
> _not_ block the UI _although_ it is implemented using two
> delays; you can drag the box around while it is flashing.
> I think this is due to the modality implementation using
> the doOneSubCycle (which I frankly do not yet understand)
It's just a recursion into event processing. It allows the world to 
display, but also user input to be processed and #step processing. In my 
#flash, try using #doOneCycleNow in place of #displayWorldSafely. You 
may be a bit happier with the results.

Cheers,
Bob

>
> Best
> 	-Tobias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
>
> iEYEARECAAYFAlIUy0IACgkQcPVIrP6PLKt4PQCggapRrM5yo4Brj+XVOO0/+jov
> L6EAn39Zw1Fpu8PN3i83Lcc5U201oEMp
> =QU+5
> -----END PGP SIGNATURE-----
>
>



More information about the Squeak-dev mailing list