Since Parsec unfortunately seems to lack any sort of externally-available issue tracker, I've decided to just put them all in a GitHub Gist and just link it in the Parsec Discord ;P
① Parsec fails to correctly switch to relative mouse movement when running games that use the LWJGL 2.x library (such as Minecraft <= 1.12.2)
When attempting to run any game that uses the LWJGL 2.x library (the most popular example being Minecraft 1.12.2 and below), Parsec will fail to detect that relative mouse movement is required, and incorrectly attempts to use absolute mouse movement which results in broken mouselook functionality.
This is what causes the "rapidly spinning camera" behaviour that some users may report.
② Parsec always reads and passes through mouse movement to the host while it is in macOS fullscreen mode (despite not being the active/focused app)
On macOS clients, if Parsec is in fullscreen mode and you switch away from it to another app while still connected to a host, Parsec will erroneously continue reading your mouse movement and passing it through to the connected host.
Note that while Parsec is in this state, it will not pass through mouse clicks, only mouse movement.
If Parsec is instead being run in a windowed state — regardless of whether it is in the same Space (virtual desktop) or another one — then this issue does not occur.
③ Parsec needlessly uses the dedicated GPU in a GPU-muxed macOS system while not connected to a host (idling in the main UI)
On macOS clients, Parsec will activate the dedicated GPU so long as the app is open, even when it is simply idling in the main UI.
I see that you are (correctly!) utilising the NSSupportsAutomaticGraphicsSwitching key in your Info.plist, so the issue likely lies somewhere in Parsec's UI rendering process.
It may also be an issue upstream in some framework/library used by Parsec, like libmatoya (which upon further thought, may very well be the cause of ③ entirely…)
④ Parsec's macOS app bundle has incorrect capitalisation of the "MacOS" folder containing the parsecd binary (which also slightly breaks code signature verification)
Parsec's app bundle capitalises the directory as "Macos" which is simply… wrong.
This effectively means Parsec only "accidentally works" on macOS at all, and anyone trying to run Parsec from a case-sensitive filesystem (APFS and HFSJ+ both have case-sensitive variants certain users may be using) will be unable to successfully launch Parsec.
Additionally, this also slightly breaks code signature verification, since the path to the codesigned binary is expected to be /path/to/Parsec.app/Contents/MacOS/parsecd.
(You can verify codesigning-related details via codesign -dvvvvvv /path/to/Parsec.app.)
⑤ Parsec inexplicably crashes on some systems running macOS 11.x (Big Sur) when attempting to connect to a host — possibly VideoToolbox-related?
I haven't personally experienced this one (as I do not have any machines that are running macOS 11.x), but a friend of mine has, so I'm effectively filing this issue for her.
Basically, if you try to connect to a host on… some macOS 11 systems, Parsec will just… crash without warning.
The last two lines it prints to the log output before crashing are:
* vt_init/VTDecompressionSessionCreate[149] = -17281
MTY_ThreadDestroy: 'pthread_join' failed with error 11
This indicates to me that it might be a VideoToolbox-related issue, though I combined through the enums on Apple's official documentation for VideoToolbox and found no reference to an error code constant matching -17281. :/
This could be another permission in addition to the existing Mouse / Keyboard / Gamepad permissions.
It would make reporting issues / enhancements like these a lot easier.
③ Add the ability to explicitly choose between absolute and relative mouse movement modes (perhaps in the Cmd/Ctrl-Shift-M menu?)
I do understand the UX concerns regarding why you might not want to implement this, as most users will not quite understand the difference between the options.
That being said, I do think it'd be useful to allow the users who do know what they're doing to manually change the mouse movement mode as a quick workaround (without having to wait for a Parsec update) if issues like ① appear again with some other games or applications in the future where Parsec fails to automatically detect when relative mouse movement is required.
Perhaps putting it in the Cmd/Ctrl-Shift-M menu would work?
I came up with some examples below as far as wording goes — "Always Optimise for Games" is about as average-user-friendly as I could make it.
- Mouse Mode → Automatic / Always Optimise for Games
- Mouse Mode → Automatic / Absolute / Relative
Parsec's current behaviour reports the number of connected clients on a host, which is visible to anyone who is friends with the user on Parsec.
I think it'd be useful to have an option (host-side?) to disable this number from being reported entirely for privacy reasons.
The Parsec client currently cannot connect to more than one host at a time.
This is distinct from Parsec Warp's multi-monitor support, as the goal here is to connect to two separate machines, rather than have a multi-monitor experience from a single host.
The Intel IGPs (even as low as the HD 4000) found in modern Mac hardware provide sufficient performance for 1080p60 video decoding in my testing — it would be nice for energy efficiency if there was an option to choose between the low-power IGP and the high-power dGPU in Parsec somewhere.
A workaround does exist to run Parsec on the IGP entirely — by temporarily disabling GPU switching and forcing the usage of the IGP via the Terminal.
For reference, the commands to do so are:
- Temporarily disable GPU switching and exclusively use the IGP:
sudo pmset -a gpuswitch 0 - Restore default macOS GPU switching behaviour (automatically switch between IGP and dGPU):
sudo pmset -a gpuswitch 2
YES