[BUG] Affinity V3 freezes completely on maximum zoom level (NVIDIA hybrid / Fedora Wayland)

[DenisJosifoski]

Does an issue for this already exist?

• I have searched the existing issues
• I have ensured my environment (operating system, app launcher, etc) is up to date

Operating System and Version

Fedora 44 KDE Plasma

Launcher

RUM

Launcher Installation

Other

Other Install

AffinityLinuxInstaller.py

Wine Version

ElementalWarrior (Recommended)

Affinity Version

Mid July 26 (4646)

Desktop Environment

KDE Plasma

Description

When zooming into a canvas in Affinity V3 / Unified to the very last scroll tick (maximum zoom level), the application window completely freezes.

• At the maximum zoom level, the UI becomes completely unresponsive to mouse or keyboard input.
• Switching focus away to another window temporarily unfreezes the UI, but returning or scrolling back to max zoom locks it up again.
• Process diagnostic check shows ~104 threads created, with 70+ threads queued in kernel wait channels during Direct2D viewport scale transformation loops.
• GPU compute utilization is 0% and VRAM is ~233 MB.

System Environment:

• OS: Fedora Linux 44 (KDE Plasma 6, Wayland session, XWayland scale 1.25)
• Hardware: Intel Core i9-14900HX + NVIDIA GeForce RTX 5070 Ti Laptop GPU (Driver 610.43.03 open kernel module)
• Wine: ElementalWarrior-wine-11.12 / wine-11.14-staging-tkg
• Renderer: VKD3D-Proton 3.0.1, Vulkan renderer, native d2d1.dll wrapper

Steps to reproduce

1. Launch Affinity V3 / Unified (installed via AffinityLinuxInstaller.py / RUM) on Fedora 44 KDE Wayland.
2. Open or create any document or canvas.
3. Scroll to zoom in continuously until reaching the absolute maximum zoom scale limit.
4. On the final zoom scroll tick, the canvas and UI freeze.

Expected behaviour

Zooming to maximum scale should stop smoothly at the max scale limit without freezing or locking the UI event loop.

Screenshots

Application UI locks up completely on max zoom

Logs

OS Kernel: Linux 7.1.5-201.fc44.x86_64
Wine: ElementalWarrior-wine-11.12
Process State at Max Zoom Freeze:
- Process PID: State S/R, 104 threads
- Wait channels: 71 threads on ntsync_schedule, 13 on futex_do_wait
- GPU compute: 0%, Memory: 233 MiB allocated
- opencl.dll: Disabled via DLL override

Config

WINEPREFIX=/home/denisjosifoski/.AffinityLinux
__NV_PRIME_RENDER_OFFLOAD=1
__GLX_VENDOR_LIBRARY_NAME=nvidia
__VK_LAYER_NV_optimus=NVIDIA_only
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.x86_64.json
VKD3D_CONFIG=force_host_cached
WINE_D3D_CONFIG=renderer=vulkan
WINEESYNC=1 WINEFSYNC=0 WINE_DISABLE_NTSYNC=1
PerformancePreferences.xml: False
user.reg: "d2d1"="native", "opencl"=""

Self-service

• I'd be willing to fix this issue myself.

[DenisJosifoski]

Update: The exact zoom level where the freeze occurs is 8,232,116% (8.23 million percent zoom).

This corresponds to the single-precision floating point mantissa limit ($2^{23} = 8,388,608$). At 8,232,116%, floating point coordinate precision drops to 0, which causes Wine's d2d1 matrix transformation calculation to overflow into an infinite loop under XWayland.

Clamping the matrix scale transformation in the custom d2d1.dll wrapper below $2^{23}$ (e.g. at 5,000,000%) should prevent this float overflow freeze.

[Gamedirection]

Great root-cause work, the 8,232,116% number matching the 2^23 float32 mantissa limit almost exactly is exactly right.

Traced it further: the actual infinite loop is in d2d_point_on_bezier_segment() in WineFix's d2d1.dll source, a hit-testing function that recursively subdivides a stroked bezier curve until its error estimate drops below tolerance. Unlike a sibling function in the same file, it had no recursion depth limit. Past your zoom threshold, the transformed coordinates it computes exceed float32 precision, the error estimate stops shrinking, and it recurses forever instead of terminating.

Opened a fix upstream: noahc3/AffinityPluginLoader#58, adds the same depth cap the sibling function already uses. I could not fully build and test the patched d2d1.dll on my machine (an unrelated, pre-existing build issue in a different file blocks the full build here), so if anyone can build WineFix locally, testing this at your reported zoom level would help a lot before it merges.