Open V-Coba opened 5 months ago
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!
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 👁️
My MMF settings ("Buttons" disabled):
Today, when using Firefox, I have come across this bug 5-6 times already! 😲
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:
If you find anything, let me know!
Okay! Thanks, I'll try this version and write whether this bug appears with it or not.
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
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.
"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.
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:
If you find anything, let me know!
I've been testing this version for a day now and no problems so far!
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?
You can check out the new scheduling in this build:
... 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.
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.
"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.
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!
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:
@noah-nuebling So when using Safari do you recommend the normal build or the v-coba-2 build?
Hey there @Cipri84,
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.v-coba
build should be consistently smooth in Firefox. 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.
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.
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.
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.
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?
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...
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.
I don´t use an external monitor. I have an iMac 18,1. The resolution is 1080p.
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?
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.
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.
@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.
@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.
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
@Cipri84, thanks very much for the info!
@merlindru thank you for adding another datapoint! I've also been using the v-coba-2
build for the last few months and it's been pretty good. I think it's better than the first v-coba
build for just browsing in Safari on my M1 MacBook Air. However, I'm not sure if these improvements translate to every scenario, or if there might be some machines or some apps where the performance would be worse. I also haven't tested extensively with Firefox.
So for the next release, I plan to go back to the original scheduling (Which you can find in the first v-coba
build and in MMF 3.0.1 and below)
Do you guys think this makes sense? If there are more datapoints suggesting that v-coba-2
performance is better than that of the original v-coba
build, I might consider shipping the next version with that scheduling. But I feel like there probably should be lot of testing to make sure it's not much worse in certain circumstances or for some users.
At some point, I'd like to see if I can reduce framedrops further by synchronizing the sending of the scroll events by MMF with the rythm in which apps like Safari are rendering content while you scroll. That's the most promising idea I have for improving performance, but I don't know if it will work out. \ However, if I do this, I'll do it on a Beta branch, so that, in case there are more performance issues or other problems - like there were with 3.0.2 - only users who opt in to getting Beta updates will be affected.
Honestly I'd think switching to vcoba2 is fine, you can always revert if it leads to issues for people, right? (May be a bad approach to do it like this tho hahah)
One thing I've noticed with MMF is that, often after sleeping, MMF scrolling seems to be choppy. However, it is immediately fixed by toggling MMF off and on again
There's a noticeable difference right away
Not sure if I'm using coba2 right now or not, but as far as I remember, it was like this on both builds
You could also add a small survey thingy to the main settings tab in the MMF app, asking if scrolling seems smoother/choppier (upvote/neutral/downvote style)
That way, people who have an issue after the update would open the MMF settings and immediately know
@noah-nuebling Are there any differences in scroll functionality between licensed and unlicensed versions? Today marks 30 days since I started using the program, which worked EXCEPTIONALLY well before, so I purchased it, entered the license key, and now the scrolling performance has become very poor, especially in JetBrains IDE and Firefox
@merlindru thanks for getting back!
One thing I've noticed with MMF is that, often after sleeping, MMF scrolling seems to be choppy. However, it is immediately fixed by toggling MMF off and on again
I've also made similar experiences, but I thought that just switching windows back and forth is what fixes the performance and it's not about toggling MMF on and off specifically. How confident are you that the issues you experienced really were resolved specifically by toggling MMF on and off?
You could also add a small survey thingy to the main settings tab in the MMF app, asking if scrolling seems smoother/choppier
Hmmm that's an interesting idea! Currently I don't have the ability to show custom notifications in the app outside of update notes. But maybe I could implement something like this in the future.
@kil0ba thanks for your feedback! I've never heard about the issue of performance getting worse after activating the app until recently when there were two reviews on the Gumroad page reporting similar things. I've just looked at the source code today and I can't find any reason why the performance would be different while the trial is active. If anything, the performance should be very (very) slightly better when the trial is over.
Either way, I've refunded your purchase. I hope that's an ok solution. Let me know if you have any more questions or feedback!
More in-depth explanation: I can only think of 2 things in the source code that could change performance when the trial is active vs when it is not active:
TrialCounter.handleUse()
is called. But if the trial isn't active because you activated your license already, then this function should immediately return and it should cost basically no performance. When the trial is still running, then the Trialcounter.handleUse()
function also immediately returns. Except for the first time that you scroll on a given day, at which point the code will subtract one from your free days and set the MacMouseFixHasBeenUsedToday
state to true
. So in conclusion, the handleUse()
function should have the same performance after the trial is over, except for the first time that you scroll on any given day. TrialCounter
module also schedules a piece of code to run every 24 hours which sets the MacMouseFixHasBeenUsedToday
state to false
after 24 hours pass. This code only runs when the trial is active, and it only runs once every 24 hours. I'm not sure if having the code scheduled to run in the future has a performance impact by itself, but I don't think so. Either way, any impact that this has should make the performance worse when the trial is active not better.By the way: In my experience the JetBrains IDEs can sometimes have really bad performance in certain situations, like when you change the display resolution. Maybe there's something like that which changed about your setup around the same time you saw performance getting worse? (Aside from activating MMF?)
Description
After I updated to version 3.0.2 (22635), scrolling in Firefox starts to be jerky from time to time. Before this version, everything was always consistently smooth, but now scrolling remains the same smooth for some time, and then, after a certain time, it begins to move with noticeable jerks. I have a suspicion it's because of this change: "Mac Mouse Fix now sends scroll events earlier in the display refresh cycle, giving apps more time to process the scroll events and display scrolling smoothly. This improves framerates, especially on complex websites like YouTube.com."
I can’t yet determine exactly what steps lead to this. I just use Firefox and everything is smooth, and then suddenly the scrolling starts to be jerky.
I will continue to monitor this situation.
Steps to reproduce
–
Context
Mac Mouse Fix Version: 3.0.2 macOS Version: 14.3.1 (23D60) Mouse Model: Logitech G903
Additional Comments
–
Console Logs
–
Crash Reports
–