On Tue, Jan 16, 2018 at 10:52 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

> Actually, this should do the job in both Morphic and MVC:
>
> Project current restore
>

Nice.  Thank you.


>
>
> ​- 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
>>
>>
>>
>>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180116/27bed857/attachment-0001.html>