Re: toward a more efficient event loop

Hi Phil,
see my responses below.

Le dim. 23 août 2026 à 19:47, Phil B <[email protected]> a écrit :

> 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.
>
> Not sure. See vmParameterAt: 48.
extract from squeak source code:














*         48    various properties stored in the image header (that
instruct the VM) as an integer encoding an array of bit flags.
            Bit 0: in a threaded VM, if set, tells the VM that the image's
Process class has threadAffinity as its 5th inst var
                    (after nextLink, suspendedContext, priority & myList)
            Bit 1: in Cog JIT VMs, if set, asks the VM to set the flag bit
in interpreted methods             Bit 2: if set, preempting a process puts
it to the head of its run queue, not the back,                     i.e.
preempting a process by a higher priority one will not cause the preempted
process to yield                         to others at the same priority.
            Bit 3: if set, tells the VM that the image's Process class has
'osErr' as its 5th or 6th inst var                     (after nextLink,
suspendedContext, priority, myList, & threadAffinity (if bit 0 is set))
            Bit 4: in a Spur VM, if set, causes weaklings and ephemerons to
be queued individually for finalization             Bit 5: if set, implies
wheel events will be delivered as such and not mapped to arrow key events
            Bit 6: if set, implies arithmetic primitives will fail if given
arguments of different types (float vs int)             Bit 7: if set,
causes times delivered from file primitives to be in UTC rather than local
time             Bit 8: if set, implies the VM will not upscale the display
on high DPI monitors; older VMs did this by default.*

Note that Cuis source code is inexact about bit 6 and 9, that's why I took
the comment from Squeak,
The VM will deliver mouseWheel if
    (Smalltalk vmParameterAt: 48) anyMask: (1 bitShift: 5).
which is true in latest Cuis. So apparently Cuis handles scroll events from
trackpad.

Anyway, I noticed that response to other events like mouse moves also feel
snappiest in Cuis than Squeak, so it's not just scroll events.
(for example, when selecting some text thru trackpad drag or when hovering
over buttons in a bar, MessageSet being a good example, or even hovering
over a Menu)

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.
>
> Yes, the VM already aggregates some scroll events, but not based on a time
frame, rather based on a scroll threshold.
I suspect that a higher resolution display also comes with a higher
resolution scroll, that may result in more events delivered, and/or we
might also get a problem of device dependent scroll units. So recent
macbooks would somehow be penalized.

One root pointer for inspecting related VM changes is
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/41

[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]

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