Affinity Suite V2 on Linux [ Wine ]

[Sorn]

It's admirable the amount of work and care displayed in this thread. Hats off!
 

Is the experience of the actual Affinity software any good after installation, though? Or are there any hopes moving forward that it will be somewhat on par with Windows or Mac experiences?

Feel absolutely free to ignore me here, of course. I just wonder if it is actually viable to work with Affinity software in Linux/WINE at this point in time with the solutions available to us.

What I can see is that as a proof of concept this all thing is invaluable. It shows that with some involvement from the company this could potentially work, besides the optimal solution of publishing a Linux port that they seem to flat out reject (or that is my understanding) for their own reasons.
 

Anyway, I just wanted to show my admiration for the work and care put into this endeavour and I also was wondering if anyone can reliably produce work with it once installed.

[Grunt]

2 hours ago, Sorn said:

Is the experience of the actual Affinity software any good after installation, though? Or are there any hopes moving forward that it will be somewhat on par with Windows or Mac experiences?

Feel absolutely free to ignore me here, of course. I just wonder if it is actually viable to work with Affinity software in Linux/WINE at this point in time with the solutions available to us.

Well, it works for starters. You might not be aware but Serif's software has been tested by man users in Wine for long time. Look. I presume, mostly very unsuccessfully. Affinity Suite (v2) doesn't deserves Garbage rating. Definitely not. But yes, as with any software there is many bugs, crashes, different glitches and even freezes. Some identical to Windows, some unique for Wine. What Affinity deserves as of right now is thorough testing. I believe crashes are caused by another unfulfilled dependencies or things yet not implemented in Wine. I would appreciate some coordinated effort or thread for testing and identifying bugs. Then maybe it might get "on par with Windows experiences".

Until now I haven't been able to test Affinity on Wayland (not on Debian), but as I have Affinity on Fedora/KDE i guess now is right time to test dxvk.

3 hours ago, Sorn said:

t shows that with some involvement from the company this could potentially work, besides the optimal solution of publishing a Linux port that they seem to flat out reject (or that is my understanding) for their own reasons.

Yep. As of now no plans for supporting Linux. So community effort it is. As always.

[Sorn]

Aaalrighty then, I shall try to follow the whole WINE install and configuration and the Affinity software on top myself as well.
I'm running a variation of Arch in X11, I'll have to sift through the posts here to see the actual procedure to follow and hopefully I'll manage to make it work.

It'd be useful to have a dedicated thread for testing and reporting what's working and what's still not there yet, as you suggested, yes. A thread just for the installation and another for the actual use of the software in Linux could be of use going forward.

For now, I'll try to make sense of all that's here to see if I can find what to do and how. It's been a long time since I tried WINE and I'm a tad lost.

Thanks again for all your efforts and taking the time to answer me back!

[Sorn]

Well, I'm fantastically lost.

I'll give it a go at a later point in time. Maybe some how-to guide will come out of it. Right now, I got overwhelmed with the amount of information in this long thread.
Admittedly, I don't have a lot of time to sit and go through it all.
 

If work gives me some spare time I'll give it another go. Maybe some more savvy chap could compile the procedures in a guide for users to try this out. That could favor having enough users trying it out and share progress, bugs and workarounds.

Thank you again, though. Good thing this is working.

[Wanesty]

2 hours ago, Sorn said:

Well, I'm fantastically lost.

I'll give it a go at a later point in time. Maybe some how-to guide will come out of it. Right now, I got overwhelmed with the amount of information in this long thread.
Admittedly, I don't have a lot of time to sit and go through it all.

it is not completely updated with Grunt's research but the updated "guide" on codeberg should be very beginner friendly !

  

On 7/30/2023 at 5:29 PM, Sorn said:

Is the experience of the actual Affinity software any good after installation, though? Or are there any hopes moving forward that it will be somewhat on par with Windows or Mac experiences?

pretty far from native experience stability wise, however most non hardware related* features are working
* screen size and hw acceleration

  

6 hours ago, Sorn said:

It'd be useful to have a dedicated thread for testing and reporting what's working and what's still not there yet, as you suggested, yes. A thread just for the installation and another for the actual use of the software in Linux could be of use going forward.

issue tracking is one one the reason for moving to a codeberg repo
(speaking of i should make issue templates..)

Edited July 31, 2023 by Wanesty

[Snapseed]

20 hours ago, Grunt said:

Well, it works for starters. You might not be aware but Serif's software has been tested by man users in Wine for long time. Look. I presume, mostly very unsuccessfully. Affinity Suite (v2) doesn't deserves Garbage rating. Definitely not. But yes, as with any software there is many bugs, crashes, different glitches and even freezes. Some identical to Windows, some unique for Wine. What Affinity deserves as of right now is thorough testing. I believe crashes are caused by another unfulfilled dependencies or things yet not implemented in Wine. I would appreciate some coordinated effort or thread for testing and identifying bugs. Then maybe it might get "on par with Windows experiences".

Until now I haven't been able to test Affinity on Wayland (not on Debian), but as I have Affinity on Fedora/KDE i guess now is right time to test dxvk.

Yep. As of now no plans for supporting Linux. So community effort it is. As always.

^ Exactly this. While they cannot devote any staff time to supporting Linux, they at least tolerate discussions like this one that allow us to share our experiences in trying to get Photo, etc to run well on Linux.

[Sorn]

29 minutes ago, Wanesty said:

it is not completely updated with Grunt's research but the updated "guide" on codeberg should be very beginner friendly !

Hey, thanks! It will definitely help. I'll take a look and when I have some spare time I'll give it a go. Much appreciated!

[Grunt]

And reporting back from console depths:

I've talked with some Wine developer. Support for Wayland in Wine right now is incomplete. Is ported/implemented into mainline but now not completely. I've been able to prepare/compile extra Wine and a separate wine-prefix (--without-x --with-wayland) and it works for me:

I'm able to run Win32/64 apps without need for XServer/X11 or Xwayland natively on Plasma. If I may add, it looks surprisingly old school. Unfortunately experience is without keyboard/mouse inputs as this function seems to be not implemented yet. But back to Affinity and DXVK:

0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0024:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 00000001800725A7, 28) stub
0024:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 00007FFFFE8FCDA4, 28) stub
0024:fixme:heap:GetNumaHighestNodeNumber semi-stub: 000000000041F9A8
0024:fixme:seh:WerRegisterRuntimeExceptionModule (L"C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\mscordacwks.dll", 00007FFFFE100000) stub
0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0124:err:ole:CoGetContextToken apartment not initialised
0024:fixme:ntdll:RtlGetCurrentProcessorNumberEx (000000000041B3D8) :semi-stub
0024:err:winediag:ntlm_check_version ntlm_auth was not found. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
0024:err:ntlm:ntlm_LsaApInitializePackage no NTLM support, expect problems
0024:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 00000001316EAEF1, 28) stub
0024:fixme:nls:get_dummy_preferred_ui_language (0x8 0x405 000000000041C9A4 0000000000000000 000000000041C9A0) returning a dummy value (current locale)
0024:fixme:nls:get_dummy_preferred_ui_language (0x8 0x405 000000000041C9A4 000000001B0538D0 000000000041C9A0) returning a dummy value (current locale)
0024:fixme:virtual:NtFlushProcessWriteBuffers stub
0024:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 000000000155F330, 51) stub
0024:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0000000001568F20, 64) stub
0024:fixme:ntdll:NtQuerySystemInformation (0x000000ce,0x41bbe0,0x00000008,(nil)) stub
0024:fixme:bcrypt:BCryptGetFipsAlgorithmMode 000000000041B9B0 - semi-stub
0024:fixme:ver:GetCurrentPackageFullName (000000000041E440 0000000000000000): stub
0024:fixme:system:NtUserSystemParametersInfo Unknown action: 8220
0024:fixme:combase:RoGetActivationFactory (L"Windows.ApplicationModel.DesignMode", {2c3893cc-f81a-4e7a-b857-76a80887e185}, 0000000000419DC8): semi-stub
0024:err:combase:RoGetActivationFactory Failed to find library for L"Windows.ApplicationModel.DesignMode"
0024:fixme:wintypes:RoResolveNamespace name L"Windows.ApplicationModel.DataTransfer", windowsMetaDataDir L"", metaDataFilePaths 0000000000419F38, subNamespaces 0000000000000000 stub!
0024:fixme:file:NtLockFile I/O completion on lock not implemented yet
0134:fixme:file:NtLockFile I/O completion on lock not implemented yet
0134:fixme:process:SetProcessShutdownParameters (00000100, 00000001): partial stub.
0024:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 00000000015EF2F0, 46) stub
0124:fixme:ole:thread_context_callback_ContextCallback 000000001A86FBD8, 00007FFFFE652E30, 00000000199FF820, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 0000000000000000
0124:fixme:ole:thread_context_callback_ContextCallback 000000001A86FBD8, 00007FFFFE652E30, 00000000199FF710, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 0000000000000000
0124:fixme:ole:thread_context_callback_ContextCallback 000000001A86FBD8, 00007FFFFE652E30, 00000000199FF710, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 0000000000000000
0124:fixme:ole:thread_context_callback_ContextCallback 000000001A86FBD8, 00007FFFFE652E30, 00000000199FF710, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 0000000000000000
0124:fixme:ole:thread_context_callback_ContextCallback 000000001A86FBD8, 00007FFFFE652E30, 00000000199FF710, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 0000000000000000
0024:fixme:msg:ChangeWindowMessageFilter c042 00000001
0024:fixme:dwmapi:DwmAttachMilContent (0000000000010060) stub
0170:fixme:gdi:GdiEntry13 stub
info:  Game: Designer.exe
info:  DXVK: v2.2-145-g9b019d26
info:  Vulkan: Found vkGetInstanceProcAddr in winevulkan.dll @ 0x2d4ad3f40
info:  Built-in extension providers:
info:    Win32 WSI
info:    OpenVR
info:    OpenXR
info:  OpenVR: could not open registry key, status 2
info:  OpenVR: Failed to locate module
0170:err:vulkan:init_vulkan Failed to load Wine graphics driver supporting Vulkan.
0170:err:vulkan:init_vulkan Failed to load Wine graphics driver supporting Vulkan.
info:  Required Vulkan extension VK_KHR_surface not supported

On this configuration I'm unable to create window surface. It might be:

• Something yet not implemented in Wine,
• Something wrong in Vulkan layer (vulkanloader, profile, i don't know),
• Some wrong configuration of DXVK not able to create wayland_surface,
• And this is what I'm afraid most of: My graphic card or to be more specific GPU driver not supporting VK_KHR_wayland_surface!

As visible from vulkainfo command:

Quote

Presentable Surfaces:
=====================
GPU id : 0 (NVIDIA GeForce 940M):
        Surface types: count = 2
                VK_KHR_xcb_surface
                VK_KHR_xlib_surface
        Formats: count = 2
                SurfaceFormat[0]:
                        format = FORMAT_B8G8R8A8_UNORM
                        colorSpace = COLOR_SPACE_SRGB_NONLINEAR_KHR
                SurfaceFormat[1]:
                        format = FORMAT_B8G8R8A8_SRGB
                        colorSpace = COLOR_SPACE_SRGB_NONLINEAR_KHR

So sum things up, without X11/Xlib I'm stuck. I would love if someone else could test combination of Wine, DXVK, Wayland and any application from Affinity suite to confirm this. Xlib and DXVK of course works but as Wine is still without support for "child window rendering" (winex11.drv) and for some foreseeable will be, DXVK is for me now useless.

I'm leaving this configuration still for one or two weeks and then I remove everything.

[Loren Dias]

Just for notation, I was able to modify wine-git PKGBUILD and swap in

ElementalWarrior's Git, compile and run Affinity Photo 2 just fine -- which I'm running on Sway.

https://gitlab.winehq.org/ElementalWarrior/wine

 

I did try to add the 10 patches to `wine-staging-git` [AUR] and wasn't able to build. If anyone has updated patches against staging I'd love to give it a try.

[Grunt]

@Loren Dias May I ask why Wine Staging? These are just another (mostly experimental) patches on top of existing Wine-Git branch? Or is there something useful?

[Loren Dias]

On 8/17/2023 at 11:30 AM, Grunt said:

@Loren Dias May I ask why Wine Staging? These are just another (mostly experimental) patches on top of existing Wine-Git branch? Or is there something useful?

From what I recall, there wasn't a objective or strategical thought behind the attempt, I just simply run wine-staging daily as I don't use WINE much beyond Proton and seeing if new software becomes useful,

WINE Staging did seem to have a automated patcher script which was useful. If I thought about it more, AFAIK staging is more likely to see wayland support or support of new experimental things in general sooner -- and probably more keen to accept patches that are not up to par for mainline just yet -- but I'm not an expert, just a user with an interest in R&D and problem solving.

If these threads have proven anything to me, it's that it's very likely Affinity Photo 2 will work just fine on Linux via wine in the future -- and create value for me and other professionals who do their heavy lifting on Linux.

 

If anyone knows of any additional repos or links on this topic, I'd love to follow with great interest. Specifically information about where to add the wayland flags on compilation of wine, and where and how to set the default render to OpenGL, Vulkan, etc... -- like for example, is this appended to the launch command of the Photo.exe binary, a configuration file inside the prefix? winecfg, etc... Or does dxvk automatically do this via

env WINEPREFIX="/Software/Affinity Photo 2/Bottles/Main" /usr/share/dxvk/setup_dxvk.sh install

Are there updated patches for wine-git or wine-staging I can find somewhere?

[ElementalWarrior]

37 minutes ago, Loren Dias said:

From what I recall, there wasn't a objective or strategical thought behind the attempt, I just simply run wine-staging daily as I don't use WINE much beyond Proton and seeing if new software becomes useful,

WINE Staging did seem to have a automated patcher script which was useful. If I thought about it more, AFAIK staging is more likely to see wayland support or support of new experimental things in general sooner -- and probably more keen to accept patches that are not up to par for mainline just yet -- but I'm not an expert, just a user with an interest in R&D and problem solving.

If these threads have proven anything to me, it's that it's very likely Affinity Photo 2 will work just fine on Linux via wine in the future -- and create value for me and other professionals who do their heavy lifting on Linux.

 

If anyone knows of any additional repos or links on this topic, I'd love to follow with great interest. Specifically information about where to add the wayland flags on compilation of wine, and where and how to set the default render to OpenGL, Vulkan, etc... -- like for example, is this appended to the launch command of the Photo.exe binary, a configuration file inside the prefix? winecfg, etc... Or does dxvk automatically do this via

env WINEPREFIX="/Software/Affinity Photo 2/Bottles/Main" /usr/share/dxvk/setup_dxvk.sh install

Are there updated patches for wine-git or wine-staging I can find somewhere?

Renderer is stored in registry.which is stored in your wineprefix folder.you can set it with winetricks.

winetricks renderer=vulkan

Unless you set the env var it uses the default .wine folder in your home directory.

Honestly if you want info, follow along in the mailinglist or irc, read the wiki, or read the code.

[Loren Dias]

32 minutes ago, ElementalWarrior said:

Renderer is stored in registry.which is stored in your wineprefix folder.you can set it with winetricks.

winetricks renderer=vulkan

Unless you set the env var it uses the default .wine folder in your home directory.

Honestly if you want info, follow along in the mailinglist or irc, read the wiki, or read the code.

Thanks for the leads, I'll add all this to my notes for my next session. I recall reading about that on the wine wiki, but it's still difficult to navigate, so collaboration is much appreciated, thank you.

[Grunt]

1 hour ago, Loren Dias said:

WINE Staging did seem to have a automated patcher script which was useful. If I thought about it more, AFAIK staging is more likely to see wayland support or support of new experimental things in general sooner -- and probably more keen to accept patches that are not up to par for mainline just yet -- but I'm not an expert, just a user with an interest in R&D and problem solving.

Wayland support is already there, but as ElementalWarrior's branch, it lives outside main branch and shall be ported into mainline branch. By assumption until this winter. I don't think there is much use for dxvk right now, then.

If you're really interested, follow mailing-lists, etc. Patches are there, but good luck combing them into one executable without collisions.

To begin with read at least https://codeberg.org/Wanesty/affinity-wine-docs.

[Wanesty]

On 8/19/2023 at 10:35 PM, Loren Dias said:

and where and how to set the default render to OpenGL, Vulkan, etc

Grunt already told about it but you might want to take a look at the Tips and Fixes part of the guide

 

also yea, last time i saw stuff about it, affinity isn't that close to being able to work on vanilla wine.. unless someone implement the whole dotnet winmd system completely, James(ElementalWarrior)'s fork is working with affinity but is too specific to get merged into wine.

also the big thing we're mostly waiting for is wow64(using 64bits libs to build both x86 and x64 wine) and wayland support, with child windows

[Wanesty]

@Grunt did you managed to have a window output last time you tired wow64 (with --enable-archs=i386,x86_64), also do you remember what was the last version you tried it on ?

also you did use .patches to try newer version right ? if you did could you share them here ? :)

Edited August 25, 2023 by Wanesty

[Grunt]

On 8/25/2023 at 7:26 AM, Wanesty said:

@Grunt did you managed to have a window output last time you tired wow64 (with --enable-archs=i386,x86_64), also do you remember what was the last version you tried it on ?

wine-8.13-173-g17d64ac1e02 almost month back. Everything works as usual. Why? Shall I update & recompile?

Patches here. Or simply compare repo and wine-master. I don't even track it anymore. Or should I?

[Wanesty]

3 hours ago, Grunt said:

wine-8.13-173-g17d64ac1e02 almost month back. Everything works as usual. Why?

oh okay so i might do some testing and change the guide to compile using the wow64 string on a patched 8.14 branch !

 

3 hours ago, Grunt said:

Patches here. Or simply compare repo and wine-master. I don't even track it anymore. Or should I?

yep that what i thought you did but i wasn't sure if you changed anything on them

 

@ElementalWarrior would you want to make a 8.14 branch with your implementations so i can link it with your name,
or would you prefer for me to make a new fork to link there?

(also ooc but would you prefer me to refer to you as James or ElementalWarrior on there?)

Edited August 26, 2023 by Wanesty

[ElementalWarrior]

16 hours ago, Wanesty said:

oh okay so i might do some testing and change the guide to compile using the wow64 string on a patched 8.14 branch !

 

yep that what i thought you did but i wasn't sure if you changed anything on them

 

@ElementalWarrior would you want to make a 8.14 branch with your implementations so i can link it with your name,
or would you prefer for me to make a new fork to link there?

(also ooc but would you prefer me to refer to you as James or ElementalWarrior on there?)

If people on the internet wanted you to refer to them by their names, they would just make their username their names.

https://gitlab.winehq.org/ElementalWarrior/wine/-/commits/affinity-photo2-wine8.14

[Wanesty]

i mean you did add your name on gitlab, but understood! i'll stick with using your username !

ty for the branch, i'll do some wow64 tests on it tomorrow and modify the guide with the new git checkout and maybe the new wow64 build if i find it satisfactory(the wow64 part) !

[Wanesty]

On 8/28/2023 at 12:14 AM, Wanesty said:

ty for the branch, i'll do some wow64 tests on it tomorrow and modify the guide with the new git checkout and maybe the new wow64 build if i find it satisfactory(the wow64 part) !

done !

i kept the previous iteration of the guide and referenced it as an alternative

 

edit : i'll try and compile it again with wayland support to see how usable it is

Edited August 29, 2023 by Wanesty

[Grunt]

23 hours ago, Wanesty said:

i'll try and compile it again with wayland support to see how usable it is

It's not or it should not be but keep me posted please. I'm interested too.

[ElementalWarrior]

On 8/29/2023 at 11:05 AM, Wanesty said:

done !

i kept the previous iteration of the guide and referenced it as an alternative

 

edit : i'll try and compile it again with wayland support to see how usable it is

I tried with the Wayland display set using sway. It opened, but accepted no input.

To be fair no other software accepted input either, so it might be something unique to my machine.

[azuredusk10]

Just a quick note to say that after using @Daedalus's wine-builder on the ElementalWarrior-8.14 wine branch and following the instructions from @Wanesty's guide, I got all the Affinity products installed and running on Fedora. I thought I'd share my experience of using the app on Fedora Linux. I'm running it on a Framework laptop.

I've been using Affinity Designer 2 for the past couple of days for client work for batch cropping, resizing, touching up  and exporting images. It works really well for me and it's sped up my workflow a lot.

Designer 2 crashes quite often, usually about once every hour. It's more likely to crash when I add an adjustment layer and move the sliders around too much, but it doesn't always crash when I do this. But saving regularly mitigates this for me. I can drag and drop images in, resize and move the images, create artboards, and batch export artboards with no problems at all. And that's perfect for me.

The gl renderer seems to work best at the moment, although the canvas does flicker every now and again. The vulkan renderer didn't produce any flickering, but the app wouldn't display anything without turning on "Emulate virtual desktop" in winecfg, and even when that was turned on, it wouldn't render any dialogs (e.g. renaming an artboard, or configuring an adjustment layer). Fingers crossed the child window rendering feature fixes that, as it looked very promising.

Horizontal and vertical panning works with my keyboard and my trackpad, although no pinch to zoom yet. Hopefully wine's upcoming Wayland support will add support for that.

I can't thank everyone enough for making this work. My partner is buying a Framework laptop and switching from Mac to Linux. He also uses Affinity Designer for his design work and is really excited that he will be able to continue using it thanks to all your efforts.

[Grunt]

15 hours ago, ElementalWarrior said:

I tried with the Wayland display set using sway. It opened, but accepted no input.

To be fair no other software accepted input either, so it might be something unique to my machine.

It's not bug on your side. As Wayland is ported from some branch into mainline, it isn't ported completely.  "Input not working" is one of known bugs. Work should be done until Christmas this year (if everything goes according to plan). But how did you get any output? This might be some bug unique to my machine. Distribution is Arch?