[squeak-dev] Updating the bits of a window
tim Rowledge
tim at rowledge.org
Mon Jan 15 21:37:41 UTC 2018
> On 15-01-2018, at 1:17 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Tim,
>
> On Mon, Jan 15, 2018 at 10:41 AM, tim Rowledge <tim at rowledge.org> wrote:
> For something that cpu intensive how about sticking a deliberate yield in the cycle somewhere so the rest of the system can do some work? That would help provide some chance of catching an interrupt key, something I faintly recall being a bit of a pain under the sim.
>
> Perhaps a yield in the sim code for the process check?
>
> The right place is in ioForceDisplayUpdate, which in the simulator is a no-op, but is called in all the right places (after deferDisplayUpdates is reset for example).
True, but I was wondering about having a yield to allow the wider system a play with the cpu. That may or may not be desirable, depending on what’s happening. Actually I guess that might be better done with a high-priority timer to interrupt and faff around.
>
>
> The classic simple approach is #doOneCycle, assuming morphic is in use. If you want to get all low-level and brutal you could use DisplayScreen>>#forceToScreen I guess.
>
> So what I don't see is why doOneCycle is the right call. That advances the animation clock,
It’s just the more-or-less habitual response and it let’s other morphs update; again, maybe desirable if you were to have a bunch of monitoring morphs that displayed cycles, interrupts, gc data etc.
> whereas what I want to do is simply ensure that a form submorph in a window appears on screen. I'm happy to use doOneCycle if that's the right thing but reading the code it seems to have far more effects than I want.
Sounds like whacking DisplayScreen>>#forceToScreen would be where you want to start for now
tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas
More information about the Squeak-dev
mailing list
|