Refactor Nvidia Workaround

[RayJW]

Description

This reworks the workaround for Linux system to only automatically apply to Nvidia systems, and use a softer workaround __NV_DISABLE_EXPLICIT_SYNC=1, that doesn't disable hardware rendering (thanks to this comment).
The original toggle is preserved as a last resort solution, but not enabled by default any more. This should greatly improve the user experience on Linux systems for basically every one.

Type of Change

• Bug fix
• New feature
• Breaking change
• Performance improvement
• Code refactoring
• Documentation update
• UI/UX improvement
• Build/CI or Dependency update

Changes Made

• Add Nvidia hardware detection
• Migrate settings to enable hardware rendering again on Linux systems
• Fix logic mistake in Linux detection
• Update English description to match new behaviour

Testing

• I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

• OS: CachyOS
• Hardware: Ryzen 9, 64 GB RAM, AMD GPU

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

Additional Notes

It would obviously be great if more people could test this. Ideally at least someone previously affected by the crashes to ensure it doesn't re-introduce that.

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is entirely AI-generated
• This PR is AI-generated but guided by a human
• This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
• This PR contains only blood, sweat, and coffee (AI-free)

[RayJW]

I just realized, that we could use the [webkit2gtk_nvidia_quirk](https://crates.io/crates/webkit2gtk-nvidia-quirk) crate from the mdns-browser project as an alternative.
I leave that call up to you @CyberTimon, the code would probably be cleaner, and it would require less work from our side in case things change. It does however introduce another dependency, so that's a trade-off worth considering.

[CyberTimon]

@RayJW Yes this dependency looks good. It seems pretty small and is a no-op on non-linux OS'es. Would you like to implement this dependency?

[RayJW]

@RayJW Yes this dependency looks good. It seems pretty small and is a no-op on non-linux OS'es. Would you like to implement this dependency?

Done :)

[CyberTimon]

Hi @RayJW,

Could we achieve this without adding a separate linux_gpu_optimization_migrated_v1 setting entry / migration logic?

While I know that's the cleanest option for the enduser, I'm not sure if the added maintenance overhead makes sense here. As this is my first larger application, I'd really appreciate your opinion on it.

Thanks a lot!

Timon

[RayJW]

Hi @RayJW,

Could we achieve this without adding a separate linux_gpu_optimization_migrated_v1 setting entry / migration logic?

While I know that's the cleanest option for the enduser, I'm not sure if the added maintenance overhead makes sense here. As this is my first larger application, I'd really appreciate your opinion on it.

Thanks a lot!

Timon

Honestly, I would keep it. It's just 12 lines of code, runs once, and worst case we can always remove it without any repercussions later on.
Otherwise, all current users of RapidRAW will be stuck with the mostly unnecessarily slow performance unless they manually switch the setting.

I hope that makes sense? :)

[CyberTimon]

Thanks for the explaination - that makes sense.

Have a nice evening,
Timon