Extreme Stuttering While Using Shaders In Borderless Fullscreen

[LobbyLC]

While using shaders and borderless fullscreen at the same time, the game appears to frequently stutter. This has been tested, and is reproducable, using the latest Cubes Without Borders version on both Minecraft 1.21.1 and 1.21.3. Any ideas as to why this is happening?

Further Details

• This only happens while using borderless fullscreen. The issue is easily fixable by simply disabling borderless fullscreen, but that slightly defeats the purpose of CWB.
• Despite the extreme stuttering, the game is not recognising any FPS drops. When recording the game (such as with OBS' Game Capture source), the footage can still be played back smoothly.

Mods List

• Cubes Without Borders 3.0.0+1.21.3
• Iris Shaders 1.8.0+1.21.3-fabric
• Sodium mc1.21.3-0.6.0-fabric (I also installed Sodium Extra to display my FPS in the attached video, but the issue is reproducable without it)

CWB.Issue.mp4

[Kira-NT]

First of all, thank you so much for providing such a detailed bug report! And I really appreciate the extra effort you put into recording and editing a video to demonstrate the issue, big preesh for that!

Based on the recording, it seems that the game itself doesn't stutter. Instead, the issue appears to be with how the game window is displayed on your system. Here's my working theory: your system might be under heavy load (welp, playing with shaders while also recording that can definitely be taxing on your PC :D). Since Windows doesn't recognize Minecraft as a fullscreen application, it may not give the game the priority it needs to run smoothly. As a result, the Windows compositor may occasionally miss V-Sync buffer swaps, leading to inconsistent frame times and visible stutters, because you basically see lots of the frames twice. This effect can be especially pronounced if you're using a high refresh rate monitor, like one running at 120-144Hz or higher.

For now, you can address the issue by changing the borderless fullscreen mode used by CWB from windows:windowed to windows:exclusive in the mod's settings. However, I would like to actually fix the problem properly, because windows:exclusive has its own quirks and I honestly dislike it with passion.

So, would you mind testing if manually adjusting Minecraft's process priority resolves the problem? Unfortunately, I can't provide screenshots on how to do that since I no longer use Windows, but here's a somewhat step-by-step guide:

1. Open the Task Manager by pressing Ctrl + Shift + Esc.
2. Locate the Minecraft process (it will likely appear as a Java process titled "Minecraft" or something similar).
3. Right-click on the process and select Go to details.
4. In the Details tab, right-click on the highlighted thread.
5. Select Set priority and choose High.
   • Note: Please avoid the Realtime option, as this could cause Minecraft to monopolize system resources, most likely rendering your keyboard and mouse unresponsive.
6. Check if Minecraft now runs smoothly.

If this resolves the issue, I'll make sure that Minecraft automatically sets its priority a bit higher when running in borderless fullscreen mode, so Windows treats it as more than just another generic window.

[LobbyLC]

I'm familiar with how to change priorities haha, but 'ppreciate the guide nonetheless. Here's what I got:

Setting the priority to high (while using the default borderless fullscreen type) did not help as far as I can tell, but setting the borderless fullscreen type to windows:exclusive did help so that works for the time being.

It's worth noting that I have a fairly beefy PC so while it's true that playing with shaders and recording simultaneously could be taxing on my PC, it should definitely still be able to run smoothly. If playing in regular fullscreen and borderless fullscreen changes how Windows prioritises the game though, it would explain why there's an extreme difference between the two.

[Kira-NT]

I'm familiar with how to change priorities haha

Well, you never know (and shouldn't assume) how tech-literate the person on the other side of the monitor is :)

Setting the priority to high (while using the default borderless fullscreen type) did not help as far as I can tell

Sigh, I was really hoping it would be as easy to fix as Thread.getCurrentThread().setPriority(10). That said, maybe it's still worth exploring if Windows' "High" isn't actually the highest non-Realtime priority available.

but setting the borderless fullscreen type to windows:exclusive did help so that works for the time being

Just out of curiosity, does windows:borderless work in your scenario as well?

It's worth noting that I have a fairly beefy PC so while it's true that playing with shaders and recording simultaneously could be taxing on my PC, it should definitely still be able to run smoothly.

Oh, absolutely - it's not about your PC being able to run the game smoothly at all (as we saw in your recording, it actually performs quite well by itself). The issue is more about how the system prioritizes certain actions over others and the order in which those actions end up being executed.

[Kira-NT]

Could you please download the patched mod version from https://github.com/Kir-Antipov/cubes-without-borders/actions/runs/12069230075, so we can definitively determine whether changing the priority - both thread- and process-wise - has no impact on the issue, or, hopefully, resolves it in the end of the day?

[LobbyLC]

Well, you never know (and shouldn't assume) how tech-literate the person on the other side of the monitor is :)

Yeah I gotcha haha, my bad if that came off as rude or anything. 😅

Just out of curiosity, does windows:borderless work in your scenario as well?

Yup! It doesn't seem as though there's any stuttering while using the windows:borderless or windows:exclusive modes, the issue seems to revolve around the default (windows:windowed) mode specifically.

(Actually, windows:borderless is rather convenient as OBS is able to detect Minecraft as a fullscreen application, which also isn't the case when using the windows:windowed mode - might have to stick with this in the future xD)

Anyhow, I'll test the patched mod version now, gimmie a moment...

[Kira-NT]

Yeah I gotcha haha, my bad if that came off as rude or anything. 😅

Oh, don't worry, it absolutely did not! :)

Yup! It doesn't seem as though there's any stuttering while using the windows:borderless or windows:exclusive modes, the issue seems to revolve around the default (windows:windowed) mode specifically.

Great! Unlike windows:windowed, windows:borderless operates as a true fullscreen mode. However, I no longer set it as the default because Discord's overlay doesn't work with it - and since almost everyone uses Discord these days, that's quite an issue.

On the other hand, windows:windowed forces the application to remain in windowed mode, which resolves many problems associated with other fullscreen modes, however, unfortunately, in your scenario this creates a new issue: Windows doesn't treat Minecraft as an important process, that deserves its window to be refreshed ASAP, anymore.

(Actually, windows:borderless is rather convenient as OBS is able to detect Minecraft as a fullscreen application, which also isn't the case when using the windows:windowed mode - might have to stick with this in the future xD)

I'm aware of that issue, and I even submitted a PR to obsproject/obs-studio (since it's technically an OBS bug) a few months ago. However, it still hasn't been merged.

[LobbyLC]

I've been experimenting for a few minutes, and it would seem as though the patched mod version does help. It still doesn't feel quite as smooth as the vanilla fullscreen mode, but maybe that's just me - at the very least, it's definitely playable.

It's worth noting that up until now, I've mainly been using 1.21.1 to test, partly due to the fact it's my primary version, and partly due to the fact that's where I've found the stuttering to be more significant - I'm only now realising that the mods I listed in the original comment were the 1.21.3 versions so that's on me. Either way, I tested the patched mod version on both 1.21.3 and 1.21.1 just to be sure, and it appears to help a lot on both.

[LobbyLC]

(since it's technically an OBS bug)

Interesting, I honestly just always assumed that it was something that came naturally "due to how borderless fullscreen works" or something, hence never reporting it. It's not difficult to make OBS capture a specific window so it's not a major issue anyway haha - good to know though!

(And, yes, Discord is one of the primary reasons I use borderless fullscreen xD)

[Kira-NT]

I've been experimenting for a few minutes, and it would seem as though the patched mod version does help. It still doesn't feel quite as smooth as the vanilla fullscreen mode, but maybe that's just me - at the very least, it's definitely playable.

Yay! Thanks for testing this out! I think setting only the thread priority through Task Manager didn't help because, according to the Win32 documentation, setting THREAD_PRIORITY_HIGHEST for a NORMAL_PRIORITY_CLASS process results in a base priority of only 10 out of 31. Here, I changed both the thread and process priority to THREAD_PRIORITY_HIGHEST and HIGH_PRIORITY_CLASS respectively, which gives us a base priority of 15 out of 31.

Technically, if the game still doesn't run smoothly, we could try pushing it a bit higher, within the REALTIME_PRIORITY_CLASS category. I don't think this is completely unreasonable, since when playing a game, you actually kinda expect it to run with real-time priority, right? We could experiment with a combination of REALTIME_PRIORITY_CLASS for the process and THREAD_PRIORITY_NORMAL for the thread, which gives a base priority of 24 out of 31. I hope this will be enough to ensure the window refreshes in real time, while still keeping it just below the threshold where it would make your input methods unusable. Would you be willing to test that out as well?

It's worth noting that up until now, I've mainly been using 1.21.1 to test

No worries! If it weren't for Forge/NeoForge, there would be a single mod version for all 1.21.x releases. :D So, it doesn't matter that much.

Interesting, I honestly just always assumed that it was something that came naturally

OBS searches for fullscreen windows by strictly comparing their edge coordinates to those of a monitor. And in some edge-case scenarios, like the one I need to rely on here, this doesn't really work.

(And, yes, Discord is one of the primary reasons I use borderless fullscreen xD)

Welp, sadly, windows:borderless isn't for you then, I guess - unless the Discord folks have fixed the problem on their end already, of course :D

[LobbyLC]

Would you be willing to test that out as well?

Sure thing, how exactly would I do that? Would I need another link from you, or is that something I change via task manager?

[Kira-NT]

Thanks a lot! Once this workflow - https://github.com/Kir-Antipov/cubes-without-borders/actions/runs/12072732079 - finishes building the mod, please check if the higher base priority improves things and whether your system remains responsive overall. As a word of caution, since I'm unsure if setting a priority of 24/31 is too high for a graphical app, please, save all your important work beforehand. If Minecraft takes precedence over your mouse/keyboard, you might need to reboot your PC :D

[LobbyLC]

This definitely appears to be the smoothest version so far - if the priority being as high as it is becomes a risk to things like the keyboard and mouse, I do think the previous version would still suffice, but in my case, my keyboard and mouse were fine, and the stuttering was greatly reduced so that's a plus.

That being said though, I also just tested the latest release of the mod again to compare the difference, and I'm weirdly unable to reproduce the original stuttering. I have changed absolutely nothing since creating this issue so now I'm just utterly confused - typically the lack of stuttering would be a good thing, but the release suddenly working now has me questioning whether the increased prioritiy is actually making a difference, or if my PC has somehow disregarded the issue altogether - do you have any ideas as to why that could be the case?

I apologise for the confusion, but I myself am super confused as to why the stuttering has just randomly... vanished. 🤦‍♂️

[Kira-NT]

This definitely appears to be the smoothest version so far

Awesome! Then I'm gonna leave it at that.

if the priority being as high as it is becomes a risk to things like the keyboard and mouse, I do think the previous version would still suffice, but in my case, my keyboard and mouse were fine, and the stuttering was greatly reduced so that's a plus.

It's not that this priority value poses a risk (if it works, it works); the issue is that I don't know which one does, because Microsoft's documentation is historically pretty mid. It provides just enough information to give you a basic understanding of what's going on, but not nearly enough to cover all the important details.

Take this case, for example: they specify that system interrupt processing occurs somewhere within the REALTIME_PRIORITY_CLASS, but they fail to clarify its exact priority range. Furthermore, they provide no examples to illustrate how different priorities are handled by the system.

Anyways, my interpretation is that the REALTIME_PRIORITY_CLASS + THREAD_PRIORITY_NORMAL combo designates an application as important enough to receive real-time updates without making it appear like a critical process. Given your testing, this interpretation seems to check out with reality.

do you have any ideas as to why that could be the case?

More likely than not, these are typical Windows shenanigans. When Windows runs background tasks - like sending user data to advertisers or downloading/applying updates - these processes are given absurdly high priority over everything else, because Windows consistently prioritizes its own operations over the user's work. This was one of the many reasons I moved away from Windows, even before privacy concerns became a significant enough issue for me.

I suspect Windows was doing something update-related in the background, as these tasks are notoriously resource-intensive, so lower-priority processes - like a humble Minecraft window - were likely getting throttled a bit. However, once Windows finished whatever it was doing, the issue disappeared, and so you stopped experiencing those horrible stutters even without the priority fix.

Whatever it was, it's bound to happen again and will almost certainly affect other players too. So, thanks a lot for bringing this to my attention regardless! :)

[LobbyLC]

No worries - glad I was able to help! :)

[LobbyLC]

Hey - very sorry to bring this back, but as of just a few minutes ago, the stuttering has decided to return. Again, I've changed absolutely nothing as far as I'm aware, but I'm now realising that the higher priority build you asked me to test before isn't making a significant difference. I figured you should be aware of this before next updating the mod as I'm now unsure whether this issue is actually resolved or not.

I really don't have any new details here - who knows what Windows is running in the background, but I can say I'm using the exact graphics drivers, Minecraft version, mods and shaders so I'm a little clueless as to why the stuttering keeps appearing and disappearing. If there's anything else you'd like me to test, just let me know!

[Kira-NT]

Thanks a lot for the notice!

Welp, it's a shame, I really hoped this would solve the issue. If it's not a priority thing, could we be looking in the wrong place? Is there anything else you're doing on your PC when these stutters occur? The only other time I saw something similar (though to a much lesser degree), the person was also using OBS to record their gameplay. Maybe there's a connection there?

[LobbyLC]

When the stuttering returned yesterday, I don't believe I even had OBS open. Even so, I just put that to the test, and the stuttering is still there when the only open app (at least on my taskbar) is Minecraft. As far I know, nothing is changing between my multiple tests, but of course, anything could be happening in the background that I'm not aware of.

Here's an interesting discovery I made while typing this comment though - the lower I cap my FPS, the less apparent the stuttering seems to be. This is extremely tempremental, it's hard to say what does or doesn't fix the issue, but the lower the cap, the more smooth the gameplay seems to be, at least for a while. Could this have anything to do with it? 🤔

[LobbyLC]

I'll expand on this:

• When I made the realisation lowering the cap helped, I tried setting the cap to 180 FPS, and for a very brief moment, the stuttering seemed to vanish. Though, it reappeared shortly after.
• I next tried setting the cap back to Unlimited and enabling V-Sync, but this made absolutely no difference to the stuttering.
• Finally, I tried setting the cap to 120 FPS. This is where I'm currently at, and while I'm still waiting to see if anything changes as it did with the 180 FPS cap, it seems to be completely smooth as of typing this.

I thought this was interesting as you earlier mentioned inconsistent frame times and visible stutters being more apparent on higher refresh rates, and I typically play with uncapped FPS on a 240hz monitor. That being said though, moving the Minecraft window to my other monitor, which has a slightly lower refresh rate, or even lowering my refresh rate via display settings, does not help.

I wouldn't really know if this information is relevant or not, but I figured I'll tell you everything I know, and maybe something here will spark your interest. ¯\_(ツ)_/¯

[mrchristensen]

I too was having the same issue. I'm not sure if it was a driver update or an update that you pushed, but my stuttering when away (while using Iris shaders). And I'm using the default windows:windowed setting. I'm on Windows 10 with a 4090.

Never mind, the stuttering/low frame rates came back