ElementalWarrior

Run winecfg and make sure you have your windows version set to something new, like windows 10

Wine doesn't use windows drivers. But OpenCL isn't going to be a direct mapping to windows drivers. Its a library that translates function calls to being called on your gpu. Linux has native OpenCL drivers, so in theory wine will take the windows OpenCL library calls, and call the linux native OpenCL library. Which will then utilize your gpu. Problems here could include: 1. Do you have the linux native opencl packages installed for your gpu. 2. How full is wine's implementation of opencl calls to native opencl libraries. 3. Is your wine version compiled with opencl support 4. Is linux opencl native supporting your graphics card? Does it support it well? 5. Does wine call opencl functionality that isn't supported by your card.

But I suppose not new enough for the changes other than mine.

Well. 8.6 is still greater than 8.2

As Vaniglia seems to be usebottles "vanilla" (mostly) wine. https://docs.usebottles.com/components/runners

Yeah I'd refrain from trying to debug this until you install a more recent version of wine. Either building my branch, or trying v1 on vanilla wine.

Ah, I stand corrected. Checking the submodule on the git repo I linked. It's using wine 8.0. I would probably not recommend using wine-ge for Affinity then. It's more gaming oriented anyway.

wine 8.14 is 12 minor versions newer than wine 8.2. So you will have my changes. wine-ge is a custom build maintained by a guy who's handle is GloriousEggroll. Pretty sure that's what GE stands for. https://github.com/GloriousEggroll/wine-ge-custom So you're at the mercy of what he builds if you're using wine-ge. Look in the console a the same time you get that error, and see if you have logs about FIXME's or ERRORS.

1. RoResolveNamespace I hacked in RoResolveNamespace calls specifically to get photo running: https://gitlab.winehq.org/ElementalWarrior/wine/-/commit/3de8daf601acd6d6f4dd95c7cba842050049e685 So any lines about RoResolveNamespace not followed by Found ... aren't resolving properly. RoResolveNamespace docs: Determine the direct children, types, and sub-namespaces of the specified Windows Runtime namespace, from any programming language supported by the Windows Runtime. Its responsible for looking up types, etc for the runtime. Which is used by C#, and WinRT/ C++/CX. So if I didn't hack in the path to the winmd files, it isn't going to resolve those types properly. WinRT is window's effort to export headers/have an interface for any language to look up types, or build bindings to their libraries. 2. Fixme's Fixme's are logging statements, written by wine devs as the stub out, or point out missing functionality. In effect, because the functionality is missing, our linux code will IN THEORY perform FASTER than windows, because it is doing less work. If you have concerns that the logging itself is slowing your application performance, turn off application logging `WINEDEBUG=-all` The fixme's are there to give other devs a heads up, that if something isn't working properly, and you see the fixme, that maybe if you implement this functionality, your application may work. 3. File dialog In my experience, you only have folder selected if it has a background on the list entry in the left panel. So it kinda looks like you have no folder selected. Although experiences in that dialog may depend on the linux distribution you are using vs what I am using. I had the best experience with it by opening the checkboxes FIRST, then ONLY selecting a folder by clicking the text, for the folder I wanted to browse/save to.

10 months ago vs 12 months ago. The one I linked is similar to the one you linked. I just took out a bunch of maybe controversial changes so it would get merged. It should address the saving issues. And would be in somewhere along the lines of wine 8.2 or 8.3

Closed means it wasn't merged. You want this link: https://gitlab.winehq.org/wine/wine/-/merge_requests/1444/diffs. This was merged.

Rebuilding for a different instruction set is trivial compared to changing your 3M line of code software to use an entirely different set of window, filesystem, keychain, network, etc libraries. Drop the criticism of Serif on this thread. They don't "simply" support Linux for the same reason not everyone here is debugging, patching and upstreaming wine code. It is time consuming, not straightforward, and requires expertise. The more people rag on Linux support on serifs own forum, the more likely they will be to just lock every thread talking about Linux.

Look for logs in the terminal that have to do with writing to file and the term "fixme" or "stub". The function is probably not implemented in wine

Ok, here is a branch based of off their downstream wayland code. No flickering with vulkan rendererr. Based off of wine 8.3. Honestly the most stable I've seen it. affinity-photo2-wine83-alf-wayland branch on my winehq gitlab

Yeah I just tried sticking the wayland mouse MR on top of my branch, and I see the same thing. file menu doesn't open. If I use the new file dialog and open a new window, it just stops accepting input and leaves the cursor with the pan/drag cursor I don't have any inside information here bud. I read the wine email list digest. You can search here for what has been upstreamed, and what is in progress. The mouse PR still has back and forth comments. https://gitlab.winehq.org/wine/wine/-/merge_requests From the looks of it, their independent branch of wayland work is here: https://gitlab.collabora.com/alf/wine/-/tree/wayland There appear to be hundred(s) of commits over a couple years. So its going to take them a bit to propose, address comments, and upstream all their changes. I might spend a bit of time rebasing off of that branch, and see what happens.