gtk3-mushrooms VS LatencyFleX

It is not about KDE/Breeze, from what I have read, the issue is with GTK(3.) One fix, not 100%, but almost pefect fix is to switch out GTK3 with GTK3-Classic.

GTK3 does indeed suck. That's why I run it with these patches.

Unfortunately they also lost tons of functionality in the process. The fact that typing on a file picker starts a recursive search instead of simply jumping to the file/folder with the prefix you typed, is nothing short of hilarious.

Gtk-classic is the only thing that keeps me sane https://github.com/lah7/gtk3-classic

The KDE Server-Side Decoration is also really powerful, allowing easy Maximize Horizontally/Vertically, window shading/hiding, and moving windows between virtual desktop/workspace, all while being able to be hidden when maximized for that extra screen space when I'm on my old 768p laptop and why I use gtk3-classic to get that SSD. Also, Window Rules -- they're very, very handy to get windows and apps to start and behave in a certain way by default.

I highly recommend gtk3-classic.

It's a bug when it stalls out your computer for 2-3 seconds because the file picker is doing a recursive search through all of your files.

Luckily, the patches that fix this (along with some other bugs and anti-features) are actively maintained by community members, despite being ignored by the GNOME project.

https://github.com/lah7/gtk3-classic

gtk3-classic will move them out of the titlebar, but if you want them completely gone you're better off switching to applications that haven't fully embraced CSDs like Gedit.

The GTK3 filechooser is the reason I switched to gtk3-classic.

Use gtk3-classic.

Installing LatencyFleX on multiple different games and Proton versions was cumbersome to me. I created an install script to do that for you. Tested on Arch Linux, should work on any distribution, provided LatencyFleX is installed on the system beforehand.

Find liblatencyflex_layer.so, latencyflex_layer.dll, latencyflex_wine.dll from extracted https://github.com/ishitatsuyuki/LatencyFleX files

No and it has a vendor agnostic alternative that works better: \ https://github.com/ishitatsuyuki/LatencyFleX

Strangely, a reflex alternative is available on Linux for AMD cards (third party, open) https://github.com/ishitatsuyuki/LatencyFleX Nvidia and AMD could both implement that as a standard, but NVidia is not keen on standards, and AMD is oblivious.

If you're on linux there's LatencyFleX: https://github.com/ishitatsuyuki/LatencyFleX

https://github.com/ishitatsuyuki/LatencyFleX here you go

And this depends on what actually reflex is and doing - Nvidia love to take a standard api and giving it a brand name and strut around like they invented something new. For example, https://github.com/ishitatsuyuki/LatencyFleX seems to suggest they get similar advantages "just" using the submission timing interfaces already available in the standard graphics APIs, I wouldn't be surprised if reflex is "just" an implementation of that, possibly with an API designed to be a bit easier to integrate in game engines than the gamedev doing it themselves.

As long as you have the most recent driver version and are on Proton Experimental, you shouldn't really have to do anything. You are on a VERY old Proton-GE build, which does not include DXVK 2.0, so that's probably why you're having issues. Maybe look into LatencyFlex, but again, with these bans going around, use at your own risk.

Use LatencyFlex instead. However it might be a bit tricky to get it working. I've not yet had success using it in Overwatch 2.