Mark Ingram

Technically you could say "the one to blame for no Linux support is actually the lack of Linux desktop users, which would make the product commercially unviable" https://gs.statcounter.com/os-market-share/desktop/worldwide Windows: 75% macOS: 15% Linux: 2.75%

The WPF UI is rendered (by default) in Direct3D9. The --no-hw-ui flag disables WPF's hardware rendering and switches it into software mode. The document view is always drawn with Direct3D11 and Direct2D.

RE: canvas flickering. We use Direct3D11 for rendering the document to the screen, and Direct2D for rendering the tool.

We only use that version of .NET for the installer itself. The actual app uses .NET 4.7.2. You could extract the internal MSI from the outer installer exe by using "app_name.exe /extract" - though you'd still need .NET 3.5 to do that (you could run Windows in a VM first to extract the MSI).

No 🙂

This is off-topic for the "Share your work" forum. https://duckduckgo.com/?q=NFTs

It's not up to us to get it working on Linux - as far as we're concerned, it's an unsupported platform, regardless of whether that's native, or via WINE or anything else. With regards to the canvas flickering, it uses Direct3D11 to present the document to the screen (separate to the UI rendering in hardware, which is done by WPF/Microsoft). You may have more luck by changing the renderer to WARP in the Preferences, if that is detected (WARP is a software rasteriser for Direct3D).

The UI is rendered via WPF, which by default uses Direct3D9. You can try disabling this, and rendering the UI via software instead with the --no-hw-ui command line parameter... (noting the double hyphen at the start).

We don't need multiple threads all discussing the same topic, so I'll close this thread down in favour of the larger, older, more active one:

From Alfred's link:

What's the GPU usage showing after closing Affinity Photo?

I'm closing this thread as this forum is meant to contain work created within the Affinity applications and to gather feedback on the work. It is not intended as a catch-all location for off-topic conversations to take place.

@Tolucacan you show Task Manager in the Details view, sorted by CPU usage? I just want to confirm that it's actually Photo that is using the CPU after the image has closed.

Their OpenCL kernel compiler is much slower than it used to be. I have a sample repo demonstrating the problem here: https://github.com/MarkIngramUK/ocl-compile-benchmark Pinching the results from that repo: AMD Radeon PRO W6800 (OpenCL 2.0 AMD-APP (3354.13)): 143ms AMD Radeon RX 5700 XT (OpenCL 2.0 AMD-APP (3188.4)): 1400ms AMD Radeon (TM) R9 390 Series (OpenCL 2.0 AMD-APP (3110.7)): 53ms The top result is what I've just tried now, with the latest drivers. The middle result is what I originally filed the bug with AMD. The last result is a non RDNA GPU (i.e. unaffected by the slow compilation bug). Driver 3354.13 appears to be 10X faster than 3188.4, but that's still 3X slower than it was originally.

I'm in regular contact with AMD, and I haven't been told that, so I would suggest that the AMD support person isn't being entirely truthful there.