Updating the bits of a window

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Updating the bits of a window

Eliot Miranda-2
Hi All,

    if I have a compute-intensive foreground task what message should I insert in it to allow the UI to update the screen, either in totality or for a specific SystemWindow, or submorph?  This is for the VM simulator which is busily executing byte codes.  I want to provide a simulator implementation of ioForceDisplayUpdate, which is currently a no-op.

AdvThanksance
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

timrowledge
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 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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks "Private Enterprise" means owning a personal starship.



Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

Eliot Miranda-2
Hi Tim,

On Mon, Jan 15, 2018 at 10:41 AM, tim Rowledge <[hidden email]> 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).
 

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, 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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks "Private Enterprise" means owning a personal starship.
 
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

timrowledge

> On 15-01-2018, at 1:17 PM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Tim,
>
> On Mon, Jan 15, 2018 at 10:41 AM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas



Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

marcel.taeumel
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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas





Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

Bert Freudenberg
World displayWorldSafely

​- Bert -​

On 16 January 2018 at 11:01, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas









Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

Eliot Miranda-2
Hi Bert,

On Tue, Jan 16, 2018 at 2:05 AM, Bert Freudenberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas













--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

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

Project current restore

​- Bert -​


On 16 January 2018 at 19:48, Eliot Miranda <[hidden email]> wrote:
Hi Bert,

On Tue, Jan 16, 2018 at 2:05 AM, Bert Freudenberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas













--
_,,,^..^,,,_
best, Eliot






Reply | Threaded
Open this post in threaded view
|

Re: Updating the bits of a window

Eliot Miranda-2


On Tue, Jan 16, 2018 at 10:52 AM, Bert Freudenberg <[hidden email]> 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 <[hidden email]> wrote:
Hi Bert,

On Tue, Jan 16, 2018 at 2:05 AM, Bert Freudenberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PNG: Pass Noxious Gas













--
_,,,^..^,,,_
best, Eliot










--
_,,,^..^,,,_
best, Eliot