Fix Color Picker Zoom on Wayland

[noahc3]

This PR implements a reimplementation of the color picker for Wayland users. This fixes:

1. The black zoom preview circle which follows your cursor
   • This happens under Wayland because on Windows the color picker captures all of your desktops, allowing you to pick a color anywhere on any of your screens. While Wine under X11 reimplements the required functions to support this, Wayland does not offer unchecked access to the entire framebuffer like X11 does, so the screen capture methods are not implemented under Wayland leading to a black zoom preview.
   • This PR reimplements the bitmap capturing functions to instead capture just the contents of the canvas. This does not fully restore the behavior of the original color picker, but since you cannot move the color picker outside the bounds of the canvas on Wayland anyways, it is a good approach given the other constraints.
2. Inaccurate color selection compared to the color of the highlighted pixel in the zoom preview
   • This is not actually a bug specifically under Wine, the same behavior exists on Windows.
   • Basically, the zoom preview scales up the pixels around your cursor with a different interpolation method vs how the color value extractor grabs a single pixel color value. This means the color value picked (and shown in the color value preview below the zoom) does not always match the color of the outlined pixel in the zoom view. This is particularly an issue with the edges of vector objects.
   • This behavior makes sense, sort of. It's more "accurate" since you are picking values that actually exist on your screen, rather than what happens to exist in the zoom view. But I found it pretty unintuitive. So instead I've made it a configurable option in WineFix preferences:
     • Native: The zoom preview is fixed, but the color value being selected is unchanged from the built-in behavior.
     • Exact: The zoom preview is fixed, and the color value selection is overridden to return the exact color value of the outlined pixel in the zoom preview. This way they match, but is technically "less accurate".

Exact	Native
Picks the outlined red color visible in the zoom preview (but doesn't technically exist in the document)	Picks white, which doesn't match the zoom preview, but is what is actually at this pixel coordinate

Note: This PR does not fix the issue where the color picker cannot leave the bounds of the canvas view. This (probably?) cannot be fixed on Wayland due to intentional restrictions on how applications are allowed to draw outside of their window bounds.

However, an alternative solution is to instead use the XDG portal PickColor protocol to use a WM-level color picker implementation. I have a PoC of how this could be done, but as this would replace the Affinity color picker entirely, this may or may not be ideal depending on your desktop environment and the quality of the built-in color picker (if implemented at all!). I also need to investigate the best way to implement communication between Affinity/WineFix and Dbus since it needs to call outside of the Wine environment, and whether it should be implemented as a config setting overriding the built-in color picker or added as a new tool to the tool panel. This will be in a separate PR if feasible (maybe not in time for v0.3, we'll see).

[github-actions]

🚀 Build Artifacts Ready

Commit: ae32008
Build Timestamp: April 6, 2026 at 17:58 UTC
Build Workflow: View Run

📦 Direct Downloads (via nightly.link):

• affinitypluginloader-ae32008-x64.zip - Main loader package
• apl-winefix-ae32008-x64.zip - WineFix plugin
• affinitypluginloader-plus-winefix-ae32008-x64.tar.xz.zip - Combined package (tar.xz)
• release-archives-ae32008.zip - All release archives

[higheraims]

That's awesome, I look forward to trying this out.

[noahc3]

I have started looking at using the color picker through xdg-desktop-portal. It will 100% not be the default. Frankly the color picker available on KDE Plasma is terrible, no magnified view, no color value preview, impossible to tell what you are actually clicking on. The only upside is you can pick from anywhere on the desktop. But that's probably a big enough upside to include, also the picker in other DEs may have a better user experience.

It should be relatively easy to implement. I may see if its feasible to bind it to a modifier key so you can use either the builtin color picker or the xdg color picker as needed without needing to go into preferences to change it. In the future it could be cool to add as a new tool but I think that would be best done with a new API in APL which needs more thought.

I am not 100% sure if xdg color picker will be in v0.3, I will try but if it shapes up to be a bit complex I'll push it out to a future release.

Next steps are building the settings API in APL.

[noahc3]

#28 implements the necessary settings API, this is now unblocked and planned for v0.3

[noahc3]

After doing some digging into the native code, there is an important difference between the native and exact modes:

• Exact: Pick the exact color of the highlighted pixel in the zoom preview. Samples from a screen capture in sRGB rather than the document's native color space.
• Native: Uses the built-in color sampling. When the cursor is within the bounds of the canvas, this calls the native rendering pipeline on the canvas to select the color value. This means the sampled color will use the native color space of the document, and is more likely to accurately reflect the contents of the canvas (though not perfect; scaling artifacts still occur, just less often). When the cursor is outside of the bounds of the canvas, it falls back to sampling against the screen capture.

So, exact mode removes the ability for the color picker to sample in the document color space in favor of having the color sampler match the zoom preview. If your document is sRGB this is probably fine and more intuitive, but very undesirable if you are working in CMYK or wide color gamuts.

So, I'll leave the option in to pick between them, but leave native as the default.

In theory, it may be possible to rewrite the magnifier to built the preview bitmap using the same sampling technique that the native pipeline uses. I dug into the native code a little bit, it runs the full render pipeline in a small tile of the canvas. So a buffer does exist that could be used to make the zoom preview more accurate, but it is not exposed to managed code. With a native code hooking framework, it would be possible to hook the underlying functions to expose this buffer to managed code, then build the zoom bitmap using the native buffer. This is the best of both worlds, and will be worth exploring once I start looking at implementing native code patching into APL.