Re: toward a more efficient event loop

Something to keep in mind since it looks like the Cuis MouseScrollEvent is
still based on my original implementation: it's still using the 'fake'
keyboard events from the VM which was what was (consistently) available
back then.  This has two problems:
1) it's ambiguous... did the user actually use the mouse wheel or did
they press the corresponding keys from the synthetic event?
2) it was difficult to properly support mouse wheel momentum as IIRC the
events are fairly low resolution.

It appears after we implemented mouse wheel support in Cuis (via keyboard
events) the VM enabled proper mouse wheel event support.[1]  That likely
explains a lot of the sluggishness you're seeing: Cuis is still using the
legacy simulated keyboard input events (i.e. low resolution) while your
Squeak image is (hopefully) getting native mouse wheel events (i.e.
potentially very high resolution) which the image is choking on?  If that's
the case, the missing piece is likely that Squeak (or better yet, the VM)
just needs to pre-cook the events a bit: rather than sending morphs *every*
scroll event, aggregate them a bit so that you get a scroll event and an
event count no more than every X milliseconds.   A short term workaround
could be to switch back to legacy synthetic events.

[1] Note for Cuis: it should be pretty trivial to migrate to native
events... MouseScrollEvent was designed to support this transparently to
application code: just enable mouse wheel events in the VM (if needed) then
change the event handler to trigger using the using the new event source
instead of the synthetic keyboard events.  The key thing is making sure
there's a way to aggregate the events to avoid the issue Nicholas is
encountering... the aggregation period should be configurable.  Downstream
code should 'Just Work.'

On Sat, Aug 22, 2026 at 3:18 PM Nicolas Cellier <
[email protected]> 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]