Enabling FFXIV_ACT_Plugin.dll breaks NVIDIA G-Sync

[Felys1998]

Some time ago I noticed that G-Sync stopped working when I was running ACT. I didn't come around time to do any basic troubleshooting until now, but I believe I've narrowed it down to the plugin.

What I've tried:

• G-Sync off by default in NVIDIA, ffxiv_dx11.exe set to G-Sync ON, act64 set to OFF. G-Sync is ignored.
• G-Sync on by default, ffxiv_dx11.exe set to G-Sync ON, act64 set to OFF. G-Sync is ignored.
• Disabled OverlayPlugin.dll, no effect.
• Disabled FFXIV_ACT_Plugin.dll and G-Sync resumed working upon tabbing back in to ffxiv_dx11.exe.
• If ACT is completely closed, G-Sync also works fine. It's only the combination of it being open & running the plugin.

I first started noticing this happening in FFXIV 3.5X, but I can't remember exactly when and it might've been happening as early as 3.4. Has there been changes in how FFXIV is interacted with by the plugin that could be causing it to snipe G-Sync? Is there anything more I can do to help debug this issue?

[Felys1998]

Addendum: just found if I hide all the stock overlays in the plugin, G-Sync starts working again. I don't believe this was the case before.

[Squall-Leonhart]

the overlay interferes with directx swap chain management.

not much you can do about a refresh hack being broken by code injection.

this game doesn't even need gsync and works with the least latency in windowed fullscreen anyway....

[ravahn]

This isn't really my area of expertise, but the overlays do not do DX9/DX11 injection or anything like that. They are just transparent windows that are click-through so they do not take focus away from the game.

I don't know enough about G-sync to be able to help find the issue, unfortunately, The overlay code has been basically the same for 1-2 years, so perhaps this is a change in FFXIV patch 3.5 or the NVidia driver.

There is an alternative overlay 'hide' mode that uses a different technique for showing/hiding the overlays. I don't think it will make any difference, but try that and see - it is a checkbox at the bottom of 'FFXIV Overlay Settings' tab called 'Use alternate Overlay hiding technique'.

Also, what happens if ACT is loaded but FFXIV ACT plugin is not active, and you turn on the 'Show Mini' overlay, does the problem occur with stock ACT overlays as well?

[Felys1998]

this game doesn't even need gsync and works with the least latency in windowed fullscreen anyway....

g-sync reduces tearing and jitter significantly, it makes a huge difference to me. Without it the game doesn't look nearly as smooth at 3440x1440 even on a GTX 1080. If I was playing at not-ridiculous resolutions I'd tend to agree with your assessment. Also, G-Sync hasn't required fullscreen for as long as I've had a capable monitor (last year), it works on windowed full-screen apps.

There is an alternative overlay 'hide' mode that uses a different technique for showing/hiding the overlays. I don't think it will make any difference, but try that and see - it is a checkbox at the bottom of 'FFXIV Overlay Settings' tab called 'Use alternate Overlay hiding technique'.

Also, what happens if ACT is loaded but FFXIV ACT plugin is not active, and you turn on the 'Show Mini' overlay, does the problem occur with stock ACT overlays as well?

Will give this a try tomorrow and report back.

[Felys1998]

The alternative hide mode didn't have an effect and the built in miniparse doesn't either. I also found that OverlayPlugin's overlay causes the same issue if the overlay is on top of the FFXIV window, I'm going to chalk this up to an nvidia change but I haven't got a damn clue what the last working driver was. Mildly frustrating, lol.

[milfoxton]

Did you find a solution yet? I notice the same problem gsync not working with act on screen

[DAOWAce]

4 years later I run into this issue and find out it's from ACT's overlays. Not any plugin, even ACT's basic windows drawing over the game is disabling Gsync even while in flip model via SpecialK.

Gsync is working while the overlay is hidden, however, if using something like cactbot which technically displays at all times, then Gsync will never work as long as ACT is running.

I've tried to add ACT and whatever this "CefSharp.BrowserSubprocess" is to support gsync in windowed mode, but that did nothing. Added Chrome, nothing. Messed around with various SpecialK settings, nothing. Set gsync to fullscreen and windowed (instead of just fullscreen), nothing.

There is nothing I have been able to do that's gotten Gsync working so long as ACT is showing an overlay.

Comparatively, Dalamud's (XIVLauncher) plugin overlays don't affect Gsync whatsoever. Screen can be filled with them and everything will all be working just fine. Reshade/Gshade as well.

So, this must be an ACT problem.. and I doubt ACT will ever change, as it hasn't for an entire decade, if not longer.

https://forums.advancedcombattracker.com/discussion/263/are-there-any-skins-that-allow-me-to-run-ffxiv-act-in-full-screen

This is the only mention of Gsync on ACT's website. Upon testing the method mentioned by that user, this indeed works, but required reconfiguring everything, and does not support any sort of hotkeys for hiding, leading to a big disruption in how I manage DPS meters. Unfortunately, it's affected by GShade, and I use SMAA, so the entire UI is corrupted a bit. Annoying, bothersome.. but usable.

There's also now 10 Cef processes running along with the browserhost plugin itself, cluttering up task manager and consuming far more system resources than otherwise (notably RAM, because Chromium is awful). All this, for Gsync to make the experience at 3440x1440 actually bearable.

I continue to hate computers more and more every year..

[Squall-Leonhart]

xivlauncher plugins function in process.

act overlays are a topmost configured overlay that always sits on top of the maximised window.

10 Cef processes running along with the browserhost plugin itself

Thats a problem with your configuration for ACT, you probably have more overlays enabled than you actually need, with just ffxiv plugin and the latest overlay plugin, with parse and emnity enabled, there are 4 cef processes.

[DAOWAce]

That's a problem with your configuration for ACT

Copying what the user said:

But in this case, I believe your only option is the BrowserHost plugin for XL launcher. This will inject a web browser into the FFXIV game process, similar to Steam or some FPS counter. Once you have a browser in your game, generate a URL from OverlayPlugin and use it with the game's process. (you still need OverlayPlugin running WSServer, but without an overlay active)

4 of the processes come from OverlayPlugin which are required to be running, but hidden, in order for BrowserHost to pull from the shared data. 4 of them are from that duplicate shared data being loaded by BrowserHost. I don't know where the other 2-3 come from, maybe from opening the editor, maybe backend stuff. Chromium is awful like this regardless.

Also, after posting I discovered another issue with that plugin which a user already reported (ackwell/BrowserHost#15). Sigh.

act overlays are a topmost configured overlay that always sits on top of the maximised window.

If I could test TCE for Elite Dangerous I could see if that overlay also breaks gsync in the same way.. but my install is borked so I can't. Every other overlay software I use seems to be in-process like you mention; RivaTuner, SpecialK, ReShade/GShade, now Dalamud.. and whatever else.

I don't have developer knowledge; has this always been the case with adaptive sync in any program on Windows? All I know is that Win10 v1709 apparently enabled Flip Model by default, which was then removed by the next release due to 'performance problems'. I don't know how flip model relates to any of this stuff besides being the only way to get adaptive sync working in windowed mode, which is the sole reason I try to use SpecialK in all my games, as Gsync is absolutely required for me at 3440x1440@144Hz on my 1080 Ti or else it's a stuttery mess in most games.

Might try to send something to the ACT developer about this Gsync issue, but it'd most likely be a futile effort.

Also, hi! Assuming you're the same Squall I've seen on various tech related forums over the last 2 decades.

[Squall-Leonhart]

I don't have developer knowledge; has this always been the case with adaptive sync in any program on Windows?

From what i've ascertained, it used to work on 7 and early windows 10, then nvidia made changes to windowed gsync after Creators update because of many reports that it didn't work properly, thats about when reports of ACT and Gsync not working together started to come in.

[EQAditu]

Might try to send something to the ACT developer about this Gsync issue, but it'd most likely be a futile effort.

Very futile because I don't have anything to do with OverlayPlugin, which is what is being talked about. ACT has no sub-processes. The only "overlay" base ACT has, and I control, is the window that appears when you click the "Mini Parse" button. Everything else is a 3rd party plugin...

[DAOWAce]

Wait, ACT's dev is here too? Wow.

Very futile because I don't have anything to do with OverlayPlugin, which is what is being talked about.

By the person who originally opened this issue, yes, but not by me when I discovered that the base ACT overlays broke GSync as well.

ACT has no sub-processes. The only "overlay" base ACT has, and I control, is the window that appears when you click the "Mini Parse" button. Everything else is a 3rd party plugin...

I see I said "base ACT overlay" in my previous comment, by that I meant the overlays coming from OverlayPlugin which use Chromium. Edited comment for clarity. Either way, the way these programs draw on the screen instead of in-process like what Squall mentioned is what seems to ultimately be the root issue.

I don't expect the overlay component of ACT to be entirely rewritten to inject into processes like those third party tools that don't affect GSync, so that's why I say it would be a futile effort. (...I'd still like to be idealistically optimistic, though.)