After version 3.0.2 (22635), scrolling in Firefox began to be jerky [bug] about mac-mouse-fix HOT 32 OPEN

"scrolling remains the same smooth for some time, and then, after a certain time, it begins to move with noticeable jerks."

The same thing happens in Safari.

from mac-mouse-fix.

Hey guys, thank you for your detailed feedback! I've now also experienced the periodic stuttering in Firefox and Safari.

I think this is something weird about macOS. It seems that periodically, the apps become more or less "prone" to stuttering while scrolling. This also happens with the Trackpad. When a browser is more "prone" to stuttering at the moment, it seems that heavier websites start dropping frames, while lighter websites still run smoothly.

I looked into the way that Firefox's and Safari's rendering engines schedule their drawing, and from what I could gather, they both seem to use the same mechanism (CVDisplayLinkCallback). So my theory is that there's nothing fundamentally different about what Firefox does, I think it just renders everthing faster than Safari, so you'd only notice the "proneness to stuttering" on super heavy websites, while in Safari, YouTube and Reddit are heavy enough to drop the framerates really noticably.

Another weird thing I've noticed is that I think, sometimes, the Trackpad scrolling is "prone to stuttering" and Mac Mouse Fix isn't, while at other times, Mac Mouse Fix is "prone to stuttering" while the Trackpad isn't. I'm not sure why that might be.

I also tried to look into using deeper mechanisms inside macOS to see if I can improve the synchronization with the display-refresh-rate in that way, but the only deeper mechanism I came across (using IOFrameBuffer shared kernel memory to read timestamps of the monitor's vsync events) is only available for Intel Macs unfortunately.

So I don't really know what's going on there, and I think in order to solve these framerate issues really well, Apple would have to improve some stuff inside of macOS.

However, with the scheduling tools that are available, it does seem like you can at least make a difference for the framerate.

For 3.0.2 I scheduled the scroll events to be sent right after a frame is drawn, instead of right before. I thought this helped performance in Safari, but I'm not so sure anymore. With all these inconsistencies in the measurements and the apps periodically stuttering more or less, I might have messed up the testing there.

In Firefox, the 3.0.2 scheduling definitely created periodic stutters that weren't there before. Thanks again to @V-Coba for your sharp feedback on that.

What I've done now is I've spent a few hours to search the space of the possible schedulings for the one that brings the best performance in Safari on the Reddit homepage (on my M1 MBA), and I think I've found one that works really well.

Please let me know how it works on your end. I haven't tested it extensively on Firefox, and I also have a feeling that the optimal scheduling might be different depending on how fast your CPU is or depending on which app or website you're using, so please let me know how this build works on your setup, with regards to framerates.

Interestingly, this version has the same scrolling behavior for "Smoothness: Regular" as in version 3.0.1. Is this how it should be? Or is it just my imagination running wild? xD

I haven't changed anything about that as far as I'm aware. But I personally often have strong placebo effects with these things, do you think it might be that?

from mac-mouse-fix.

Hey there V-Coba, thanks again for your detailed feedback!

I created a build of 3.0.2 where the new mechanism that sends scroll events earlier in the display refresh cycle is turned off, if you're interested in testing that out:

MacMouseFixAppForV-Coba.zip

If you find anything, let me know!

from mac-mouse-fix.

When you disable MMF, everything scrolls smoothly using native FF scrolling. That is, the problem is in the new version of MMF, not in FF. Because before the update to version 3.0.2 (22635) everything was perfectly smooth!

from mac-mouse-fix.

I have the latest version of Firefox — 123.0.1. There are only two extensions installed: Most Recent Tab and uBlock Origin.

I checked it in the latest dev version of Firefox (124.0b8) and immediately ran into these jerks while scrolling. Although everything was perfect before! Only today this started, immediately after updating MMF to version 3.0.2 (22635).

I even rebooted the operating system in the hope that it would help, but no 😥

There is a suspicion that a similar problem exists not only in Firefox 🤔 It’s just that in Firefox everything has ALWAYS been as stable as possible in this regard, so this bug immediately catches your eye 👁️

from mac-mouse-fix.

My MMF settings ("Buttons" disabled):

from mac-mouse-fix.

Today, when using Firefox, I have come across this bug 5-6 times already! 😲

from mac-mouse-fix.

Okay! Thanks, I'll try this version and write whether this bug appears with it or not.

from mac-mouse-fix.

Interestingly, this version has the same scrolling behavior for "Smoothness: Regular" as in version 3.0.1. Is this how it should be? Or is it just my imagination running wild? xD

from mac-mouse-fix.

So far in Firefox everything is smooth and without a single jerk, as it was before 👍 I will continue to monitor the situation, but it seems that my intuition did not let me down.

from mac-mouse-fix.

Hey there V-Coba, thanks again for your detailed feedback!

I created a build of 3.0.2 where the new mechanism that sends scroll events earlier in the display refresh cycle is turned off, if you're interested in testing that out:

MacMouseFixAppForV-Coba.zip

If you find anything, let me know!

I've been testing this version for a day now and no problems so far!

from mac-mouse-fix.

You can check out the new scheduling in this build:

MacMouseFixApp-ForV-Coba-2.zip

from mac-mouse-fix.

... I'm just opened 2 tabs in the same window in Safari, one with Reddit and one with YouTube. The Reddit one scrolls smoothly with MMF and is really choppy with the Trackpad, while YouTube is pretty choppy with MMF but super smooth with the Trackpad.

So the 'ideal scheduling' doesn't even seem to be consistent inside the same app at the same time. :0 I'll look further into this, but at this point I'm honestly quite confused.

from mac-mouse-fix.

I also just saw that Click and Drag to scroll was smooth while scrolling with the scrollwheel was really choppy.

They use the same mechanism to send scroll events, so this is also a bit weird. The only relevant difference I can think of is that they use different instances of CVDisplayLink, so perhaps the state of the CVDisplayLink can become desynchronzed and cause the stuttering? Or maybe the heavier CPU load of Click and Drag accidentally causes some part of the scheduling to line up so that stuttering is prevented?

Not sure, just writing down my thoughts.

from mac-mouse-fix.

"I also tried to look into using deeper mechanisms inside macOS to see if I can improve the synchronization with the display-refresh-rate in that way, but the only deeper mechanism I came across (using IOFrameBuffer shared kernel memory to read timestamps of the monitor's vsync events) is only available for Intel Macs unfortunately."

I have an Intel Mac. Wouldn't it be better to have one version of MMF for Intel and another for M chips? Just asking.

from mac-mouse-fix.

I have an Intel Mac. Wouldn't it be better to have one version of MMF for Intel and another for M chips? Just asking.

Possibly I could build something just for intel macs using the deeper mechanisms, but it’s very questionable if the deeper mechanisms would even help. My intuition is that it would not, since I think the problem is with synchronizing MMFs scroll events with the drawing of the apps that you’re trying to scroll, not with synchronizing MMFs drawing with the vsync events from your monitor. 3.0.2 already tries to sync MMF exactly with the vsync events from your monitor but that apparently didn’t really help. The only thing that the lower level APIs would allow us to do is to check when the monitors vsync events are coming in directly from the kernel and sync MMFs event sending directly with that. This would only make a difference if the higher level API we’re currently using is not actually telling us the truth about when the vsync events are coming in, which might be the case based on what I read, but I’m not sure. Maybe I could explore this more at some time, but since this won’t work on Apple Silicon machines, I don’t want to spend toooo much time on this.

The following is a pretty detailed writeup of my thoughts and observations. It's mostly for myself to try and make sense of things, but if you have any ideas regarding this, or you yourself have contradicting or supporting experiences, it would be very interesting to hear about them. Thank you.

Another thing I observed since yesterday is that I optimized the v-coba-2 build for scrolling on the Reddit homepage in Safari on my m1 Mac, and on that page, I consistently got super smooth scrolling. Way smoother than the trackpad.
But later I visited a GitHub page - which I think should be much lighter to render than the Reddit page, and it stuttered using the v-coba-2 build when it didn’t do that before. I had both of these tabs open in the same window, and saw this weird behaviour.

Now I’ve read that CVDisplayLinkCallback, which both Firefox and Safari seem to be using to synchronize drawing with the display, tries to estimate how long an app will take to draw, and to then schedule the drawing so that it is finished right before the end of a display-refresh-cycle. My theory is that, when you’re scrolling on Reddit inside Safari, the rendering takes a long time, since it’s a fairly heavy website, and so the CVDisplayLinkCallback schedules the drawing to start earlier in the display-refresh-cycle than on other websites.

Now the other part of my theory is that, for scrolling to be smooth, Mac Mouse Fix needs to send its scroll events in a certain rhythm relative to when Safari starts drawing the frame. And for the v-coba-2 build, it seems that I’ve found a good rhythm for the heavy Reddit website, which unfortunately doesn’t work well for some other sites.

I think this theory might also explain why the scrolling gets periodically better and worse. Maybe the heuristic thatCVDisplayLinkCallback uses to determine when to start drawing a frame, can slowly drift back and forward if a few frames take longer or shorter to draw than it expected, which then messes up the rhythm of the drawing relative to the rhythm of the scroll events that are coming in - and this causes stuttering.

Now this is hard to address from the perspective of Mac Mouse Fix. Ideally, Mac Mouse Fix could see exactly what rhythm another app is currently using to draw its frames. Then, Mac Mouse Fix could schedule the sending of its scroll events to fit this rhythm and minimize stuttering.

However, I’m not aware of a way to see another app’s drawing rhythm short of attaching a debugger to it, which I think is really slow and clunky, and a security risk, and would require a restart of the other app, and special privilege from Apple, so it’s probably not feasible.

There might be ways though to estimate what the rhythm of drawing in another app is like at the moment. One promising thing I found are some APIs that let you inspect CPU load. Those might be used for such an estimate, but I haven’t explored this option so far.

Aside from that, I should probably adjust the current, simple scheduling of MMF’s scroll events such that at least Firefox and light websites in Safari are pretty consistently stutter free. Heavy websites like Reddit might just have to stutter for the time being. I mean, I could detect if the user is using Reddit and then adjust the scheduling, but I think that would only work for the current rhythm of everything. And if Reddit gets faster or slower or someone has a faster or slower CPU, then the scheduling wouldn’t work anymore because the rhythm is messed up, so I really think I need to at least take the CPU load into account when trying to improve the scheduling.

Alright this is the state of my ideas and knowledge so far, if you have any ideas yourself how this might work or how Mac Mouse Fix could possibly address this, please let me know!

from mac-mouse-fix.

Notes to myself:

There seem to be multiple potential ways to get CPU usage per thread of another process. Promising ones I saw were proc_pidinfo and task_get_pid.

Also see:

• https://developer.apple.com/forums/thread/655349
• The CPU usage based heuristic I built for startup estimation for the enable-timeout-toasts in 3.0.2

from mac-mouse-fix.

@noah-nuebling So when using Safari do you recommend the normal build or the v-coba-2 build?

from mac-mouse-fix.

Hey there @Cipri84,

• The v-coba-2 build seems to be much smoother on Reddit.com for me, but on other websites such as GitHub.com it seems worse than the other builds.
• I think the first v-coba build should be consistently smooth in Firefox.
• The standard 3.0.2 build seems to be worse than the first v-coba build for Firefox.

Based on this, I would recommend using the v-coba build with Firefox if you want the best performance for browsing.

I don't know anything more at this point. I filed a report for this with Apple and will try to learn more in order get the best possible scrolling performance for MMF. If you learn anything more, please let me know.

Also, sorry for all the hassle. I shouldn't have pushed out this change in the 3.0.2 update. I should've created a Beta instead for these changes. I'll try to learn from this and handle these kinds of situations better in the future.

from mac-mouse-fix.

After weeks of switching between the standard version, V-Coba and V-Coba 2, I've come to the conclusion that neither version works properly in Safari on the Sonoma. Scrolling with either version is jerky. You have to keep turning the MMF off and on to get smooth scrolling but it will became jerky after a while.
But out of curiosity I tried the MOS app and the scrolling is buttery smooth! I stopped using MMF scrolling and now only use MOS. If MOS can be super smooth, MMF should be too. I hope that in the next update MMF smoothness will work 100% in Safari.

from mac-mouse-fix.

On my Intel-based MBP 16"2019 I see the totally opposite picture, (though I use Brave Beta instead of Safari as my daily driver) - MOS scrolling is always jerky while MMF works fine during 80% of time, then for some reason scrolling may become jerky in some tabs, then it recovers, then it may become jerky again. Jerkiness happens primarily on heavy pages with a lot of embedded pictures and/or videos.
I couldn't find any link between MMF restart and scrolling recovery, I have a feeling it is something related to the macOS itself and the way it schedules processes or uses GPU... I use my mac with external monitor, so iGPU is always off, so it is not Intel GPU <-> AMD GPU switch, it is something else, but I am not an expert and don't have enough skills to troubleshoot the problem on such level.

from mac-mouse-fix.

I use Safari exclusively because I only have Apple devices and Safari is much more integrated into the Apple ecosystem than any other browser, and I love the fact that Safari can automatically fill in 2FA codes from mail and sms. The MMF scrolling is so good when it's working properly, but suddenly it starts to get very jerky. The only way to resolve the issue is either to turn MMF off and back on again or sometimes to quit Safari. But like I said, that doesn't happen with MOS with me.
I also don't have enough skills to troubleshoot the problem on such level but I believe that the developer will be able to resolve this issue because MMF is fantastic despite this current situation with Safari.

from mac-mouse-fix.

Hey guys thanks for sharing your experiences. It's quite a confusing situation.

My experience has been very similar to @ib0ndar's. IIRC on my machine, MOS has pretty much the same behaviour as MMF and as the Trackpad. All three became stuttery periodically. I couldn't see a change by restarting MMF, although several users have reported that to me.

I wonder why different people are observing such different behaviour here. I feel like it might be connected to the setup. I seem to see the same behaviour as @ib0ndar - who is using an intel machine and brave - and I have an M1 machine and am using Safari. So it doesn't seem to be connected to the chip architecture or the browser that is being used. But I feel like it might be connected to the monitor setup.

Specifically my feeling is that if you're using multiple monitors instead of just one, the mechanism in macOS that synchronizes things to the screen refresh rate might behave differently which might explain the differences between the experience of @Cipri84 and of @ib0ndar.

I personally have an M1 MacBook with a thunderbolt Dock, connected to a 4K 60Hz monitor through HDMI. I usually have my MacBook open but the screen is just mirroring the external monitor. So I have two monitors connected, but they are in mirror mode.

What monitor setup are you guys using?

from mac-mouse-fix.

I am using 4k external monitor connected over USB-C (HiDPI like 1440p) + monitor of the macbook in dual-screen setup:

The external screen is my main one, practically I use my browser only there. Also, just to mention - I have tried following browsers and see similar intermittent stutters everywhere:

Safari
Brave
Chrome
Firefox
Arc
Orion

Also, when MMF starts to stutter and produce laggy scrolling, same laggy scrolling is observed if I try to use the trackpad. Somehow I have a feeling that it might be connected to the scaled resolution I use on the 4k external monitor as from time to time I have to use my mac on the go using only integrated monitor (but again with disabled automatic GPU switch using AMD GPU only) + mouse and honestly I have a feeling the scrolling in such configuration lags much less... But I use this setup 3-4 hours every two weeks, so I can't guarantee the absence of external monitor really makes a difference or it is a placebo effect...

from mac-mouse-fix.

Thanks for sharing this info @ib0ndar.

So you are also using 2 displays which might be relevant.

That's an interesting idea that the issue might be connected to the scaled resolution. I'm personally not using a scaled resolution on my main display but I guess the resolution on my mirrored display is scaled. I'll keep this in mind and will try if I can see a connection.

I also think it's quite hard to rule out placebo effects with these things, since the patterns of when the stutters appear seem so unpredictable and relatively random. Those kinds of placebo effects are why I shipped the changes in 3.0.2, which ended up seemingly making stuttering worse on average. So I'd definitely like to do longer term tests before drawing conclusions as to what is going on, but it's nonetheless an interesting observation.

from mac-mouse-fix.

I don´t use an external monitor. I have an iMac 18,1. The resolution is 1080p.

from mac-mouse-fix.

Hi @Cipri84, thanks for sharing this info. You said that MOS is smooth for you. How long have you been using it so far with it being smooth, and how often does MMF stutter for you? Do you think there's a possibility you just haven't used MOS long enough to encounter the intermittent stutters there?

from mac-mouse-fix.

Some more observations:

I just activated MOS, closed my laptop, so it's only one monitor without any scaling, also set to 1080p, and scrolled on the YouTube front page inside Safari and it's very noticably stuttery for me.

Edit:

Now I activated MMF v-coba-2 build and its currently very smooth on the YouTube front page.

So if MOS is really consistently smooth on your machine, that's quite curious, and none of the variables we looked into so far seem to be obviously connected to this different behaviour you see. (The variables we looked into being: chipset, browser used, display resolution, display scaling, multiple displays). Another idea may be that it's connected to internal displays vs external displays? It seems unintuitive to me that this would make a difference, but who knows.

from mac-mouse-fix.

I've only been using MOS for about two days. So yes, there´s a possibility that I haven't used MOS long enough to find the problem. Or there might be some stuttering with MOS, but it's much less than with MMF and I might get a placebo effect and it seems to me that MOS is much better, you understand?
MMF stutters quite often, it only takes a couple of hours with Safari open for the stutter to start. And by the way, I've tried Brave and I really do notice that it's super smooth with MMF, it's a shame Brave doesn't have some features I love in Safari.

from mac-mouse-fix.

@Cipri84 thanks for getting back. This is all quite hard to evaluate. If you find that MOS keeps being noticably smoother on your Mac than MMF, then it wold be very interesting if you let me know.

Also, which of the 3 versions of MMF 3.0.2 have you been using the most? (There's the base build, the v-coba build, or the v-coba-2 build) Is there maybe one build you used less than the others, and maybe have a non-representative experience with due to shorter testing time?

As far as I understand, the first v-coba build should have similar performance characteristics to MOS.

As for Brave, it's a Chromium browser, so it might have similar performance to other Chromium browsers. But the Chromium browsers that I've tested also tend to stutter just like Safari. The only Browser I've tested so far which seems ot be noticably better is Firefox.

Edit: Actually, based on my current best idea of why this is happening, which I outlined in one of the long comments above, how smooth the scrolling is could depend on the combination of the mouse app you're using and the browser you're using, and the chipset you're using, and the scaling of your monitor and the website you're on, and how busy your chip is, and semi-random fluctuations over time, and more. And it's not that these things being faster necessarily prevents stuttering. It might be that if you're on a faster chip, you need a slower browser to make the stutters better or if you're on a slower browser, you need and even slower chip or something unintuitive like that. That's because my best idea is that the stutters depend on how the rendering of the browser lines up with the timing of when the mouse app/trackpad driver sends its scroll events. And sometimes slowing things down can make those two things line up in a more favorable way and prevent stutters.

So I think that the patterns of what's stuttery and what's smooth might just be different on every setup, and there might be not much use in us trying to share this information, because there might be no single pattern that applies to all of our setups. But it is still good to see if there is a pattern between all of our setups, just to rule that out. So far I can't really see one based on the information shared by @ib0ndar, @Cipri84, as well as my own experience. Except for maybe something with internal vs external displays.

Sorry for all the rambling, I'm just also processing this information and trying to make sense of it. I hope it's not too confusing or overwhelming. Again, if you have any insights or ideas on this, I'd be very interested to hear! And thanks for sharing all this info so far.

from mac-mouse-fix.

@noah-nuebling I've used all three versions for a while and they all end up stuttering. But the version I'm using at the moment and which seems to take the longest to stutter is the v-coba build.

from mac-mouse-fix.

Wow, great work :D

I'm on a 4k 165hz screen using a scaled res. With v-coba-2, it is immediately noticeably smoother by a LOT

With all other builds, I'm noticing frame-skips every in every single scroll (not noticeable on a 60hz screen, but more pronounced on 120hz and up)

There still is some lag on heavier websites like YouTube and Twitter that isn't present with the trackpad, v-coba-2 makes things much smoother

Just wanted to add another datapoint

EDIT: clarify that there is still some lag

from mac-mouse-fix.