Re: toward a more efficient event loop

If you do not experiment sluggishness, then you probably have Preferences
higherPerformance set to true.

Here is the main method in Cuis WorldMorph handling the inter cycle delay:

doOneCycleOn: aMorphicCanvas delay: delay
    "Do one cycle of the interaction loop. This method is called repeatedly
when the world is running.
    Make for low cpu usage if the ui is inactive, but quick response when
ui is in use.
    However, after some inactivity, there will be a larger delay before the
ui gets responsive again."

    | wait waitUntil |
    self doOneCycleNowOn: aMorphicCanvas.
    (lastCycleHadAnyEvent or: [ deferredUIMessages isEmpty not ])
        ifTrue: [
            pause := 20.                "This value will only be used
later, when there are no more events to serve or deferred UI messages to
process."
            wait := 0.                "Don't wait this time"]
        ifFalse: [
            "wait between 20 and 200 milliseconds"
            activeHand waitingForMoreClicks
                ifTrue: [ pause := 20 ]
                ifFalse: [ pause < 200 ifTrue: [ pause := pause * 21//20 ]
].
            waitUntil := lastCycleTime + pause.
            "Earlier if steps"
            stepList isEmpty not ifTrue: [
                waitUntil := waitUntil min: stepList first scheduledTime ].
            "Earlier if alarms"
            alarms ifNotNil: [
                alarms isEmpty not ifTrue: [
                    waitUntil := waitUntil min: alarms first scheduledTime
]].
            wait := waitUntil - Time localMillisecondClock max: 0 ].
    (Preferences at: #serverMode)
        ifTrue: [ wait := wait max: 50 ].    "Always wait at least a bit on
servers, even if this makes the UI slow."
    wait = 0
        ifTrue: [ Processor yield ]
        ifFalse: [
            delay setDelay: wait; wait ].

This gets sent from

mainLoop
    [
        self displayWorldOn: canvas.
        [
            "Here canvas and waitDelay are passed as arguments.
            This is because when debugging Morphic, a new UI process,
            these ivars are updated, but in the debugger process we still
want the original ones."
            self doOneCycleOn: canvas delay: waitDelay.
            UISupervisor isUIProcessRunning ]
                whileTrue: []
    ] on: Error, Halt do: [ :ex | ...snip...

So, we would have to let processEvents answer whether it saw any (known
processable) event,
memoize whether previous cycle had any event in an instance variable,
implement waitingForMoreClicks the same way as Cuis (^mouseClickState
notNil),
avoid aborting processEvents at first MouseEvent,
end then we're practically ready to implement Cuis adaptative
interCyclePause.

Nicolas

Le sam. 22 août 2026 à 23:41, <[email protected]> a écrit :

> If there is a better strategy in Cuis, we should adopt it if possible.
> There is a lot of good design thinking in Cuis.
>
> Do you have a pointer (class/method) to where this is implemented in the
> Cuis image?
>
> Thanks,
>
> Dave
>
>
> On 2026-08-22 19:18, Nicolas Cellier wrote:
>
> Hi all,
> if you compare Cuis morphic feel to Squeak morphic feel, the former looks
> snappy, the latter sluggish.
> Especially if your trackpad generates a bunch of MouseWheelEvent
> (MouseScrollEvent in Cuis) whenever you're willing to scroll.
> Why is that?
>
> Squeak World goes through an interCyclePause:  at every mouse event.
> Indeed, when the hand *processEvents* it stops at first mouse event
> encountered.
>
> Hence, unless you are ready to sacrifice some battery life with a
> Preferences higherPerformance,
> the event buffer might take several seconds to drain with such strategy,
> especially on mac.
> It makes the user experience somehow catastrophic.
>
> Cuis has a different strategy:
> - processEvents drains the event buffer.
>   however, it only processes one mouse move event per cycle, and drops the
> other ones.
> - the world cycle doesn't pause if (lastCycleHadAnyEvent or: [
> deferredUIMessages isEmpty not ])
> - it also does not pause further than the next morphic step or alarm
> - the pause grows gradually from 20 to 200ms whenever there is no activity
>   but at least %)ms in server mode
>
>  Maybe it's time to revise our strategy too !
>
> Nicolas
>
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to
> [email protected]
>
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to
> [email protected]

Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]