Re: toward a more efficient event loop

Hi List,

Smooth scrolling is the bane of my existence on a Mac, especially with
cross-platform tools. (Blender is still unusable on the trackpad because of
that! I had to buy a mouse just for a real, discrete scroll wheel.)
However, I've never really noticed an issue in Squeak with the event timing
unless I'm idling, spinning the metaphorical wheel while thinking, and then
I do see it play catch-up. Maybe the computers at work keep my expectations
at Y2k? Maybe I do more thinking than inputing?

I'd like to second Nicolas' idea of folding consecutive events in the
buffer anyways. If we poll the event queue and there are 50 ScrollDown
events in a 10ms window or whatever the delay is, do we really need to
process them all, a frame at a time? I know it's helpful to have software
events so close to the hardware events that make them, but a noise filter
of some sort would be useful in that case.

Think how there's REPSPEED and KEYTIME because you're dwelling on a
keystroke while typing slowly and hooooooooooolding the key down to send
the input continuously, and how fast typists need really short dwell times
or the software misses keystrokes. I haven't done hardware events since the
TI-84, but maybe there's an OS call that can tell the difference between
smooth and regular scrolling, like how it does the same for keystrokes?

On Sat, Aug 22, 2026, 15:41 <[email protected]> wrote:

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