After version 3.0.2 (22635), scrolling in Firefox began to be jerky [bug] #875
Comments
|
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. |
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 ( 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 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.
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 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. |
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. Now I’ve read that 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 that 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 Also see:
|
|
@noah-nuebling So when using Safari do you recommend the normal build or the v-coba-2 build? |
|
Hey there @Cipri84,
Based on this, I would recommend using the 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. |
|
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 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. |
|
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 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? |
|
@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 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 So for the next release, I plan to go back to the original scheduling (Which you can find in the first Do you guys think this makes sense? If there are more datapoints suggesting that 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. |
|
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
|
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
–
The text was updated successfully, but these errors were encountered: