Actually, this should do the job in both Morphic and MVC:

Project current restore

​- Bert -​


On 16 January 2018 at 19:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Bert,
>
> On Tue, Jan 16, 2018 at 2:05 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>
>> World displayWorldSafely
>>
>
> Thanks.  It would be nice if there was a changed: call a model could make,
> e.g. self changed: #forceScreenUpdate, that could insulate models from
> being run under Morphic or ST80 managers. Someday perhaps :-)
>
>
>>
>>
>> ​- Bert -​
>>
>> On 16 January 2018 at 11:01, Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>>> Hmm... maybe "Project current world displayWorldSafely"? Or for a single
>>> morph "Display getCanvas fullDraw: self"? Well, the latter does ignore
>>> Z-Order and occlusion and stuff.
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 15.01.2018 22:37:52 schrieb tim Rowledge <tim at rowledge.org>:
>>>
>>> > On 15-01-2018, at 1:17 PM, Eliot Miranda wrote:
>>> >
>>> > Hi Tim,
>>> >
>>> > On Mon, Jan 15, 2018 at 10:41 AM, tim Rowledge 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180116/f17905ba/attachment.html>