Mark Ingram

Hi John, that's just the way we render the document to the screen.

You did - @Chris B replied: > Having a large number of fonts (thousands) installed can cause the app to load slowly on first run. It might be worth checking to see how many you have installed.

What is your Windows display scale set to? What resolution is your monitor? We adhere to the display scale that is set in Windows. If you choose 200%, everything will be twice as big, if you choose 300% everything will be three times as big, etc.

@Bugeye, a failed stop code (BSOD) indicates a problem with a driver (the Affinity software itself cannot cause a BSOD as it runs in user-mode). Unfortunately I can't tell you which driver is causing the problem, but try uninstalling and reinstalling the latest graphics drivers as a start.

This sounds like you have some software installed on your system which is breaking the rendering of the UI. I've seen this before with Duet Display. Try starting the application with the --no-hw-ui command line parameter to see if this solves the problem.

Please check my link above and see whether you have any of the applications installed (e.g. Duet Display). I can't look at your machine and do that for you.

Have you checked this post?

Thanks @makenai. Can you give me some details of your external GPU setup?

Have you tried rebooting first?

What Wacom are you using?

Glad this has helped solve your problem! You should consider changing your forum username from your email address, else it might get up by spammers.

No problem! Yes, I was a little confused too. I've still not heard back from Microsoft, will chase them about it.

And the developers do actively participate in the forum too 🙂

@MarvinR, can you just check your Tablet Input Mode in Preferences? What is that set to?

Can you attach your document?

The beta and retail latest versions are exactly the same. Do you still get a hang with the 1.8.5 retail build?

You can already create a new view, which you can drag to another monitor, and then maximise the window. You'll still see the window title bar, and possibly the Windows Taskbar at the bottom (depending on your settings). Are you referring to a true fullscreen experience? i.e. no UI visible at all?

Hi @MiME DS, this isn't a bug, we are transforming the colours from your document's colour profile to your monitor's colour profile. Nothing has changed in 1.8.4 in this area, so I would suggest that perhaps a Windows update or a driver update has changed your monitor's ICC profile? The reason other applications display white as white is because they don't do colour profile conversion (and that's the reason our UI looks correct, because we don't colour convert the UI). Now, as to why it's yellow, that's normally because of a bad ICC profile. You could solve this by changing the colour profile associated with your monitor to one that doesn't map white incorrectly (it may be worth speaking to the manufacturers of the monitor or whoever was responsible for creating your profile to find out if there is a better ICC profile to use). We have an FAQ about this: Out of curiosity, can you provide details of what your current monitor ICC profile is?

Great stuff, thanks @DQ_C. If they get back to you, feel free to point them at this thread. Also, we're always interested in speaking to users who work in 32-Bit, so would be great to know a bit more about your workflow. Are you using the HDR mode in the 32-bit Preview panel too?

I've just double checked the code, if you have a 32-bit document, we will enable the menu items if the plugin has _either_ of the following properties set: PIImageModesProperty : plugInModeRGB96 PIEnableInfoProperty : "RGB96Mode" (3 channels of 32-bit data = 96) If ArionFX uses another method of signalling it accepts 32-bit data, we would need to find out what that is. It may be worth contacting the ArionFX support / developers about this (their developers are free to contact me to discuss this further).

Assuming you don't need to copy any brushes or other content out of the folder, it can be deleted.

Can you remember what the software was, or what the link was?

Low Precision is how it used to work in 1.8.3. It uses the position from the cursor on the screen to record location data for the tools. This method is not sub-pixel accurate. High Precision is new in 1.8.4 (and was the only option in 1.8.4, without the --legacy-wintab option). It uses sub-pixel location data from the tablet directly, leading to more accurate (and smoother) input. It may also record a higher quantity of points too (more points equals more changes, therefore can slow things down).

Either follow @- S -'s advice above, or set your monitor profile to the default sRGB profile. I've reported the issue to Microsoft directly.

Some more interesting info for future reference. The Intel ICC profile header reports the size as 7032 bytes. Looking at the file size and tag data, the size is actually 7200 bytes. If I manually fix this, it doesn't make a difference, the Intel version still shows white as white. If I modify the AMD profile to have the same RGB tristimulus values as the Intel version, the AMD version no longer shows white as yellow. This looks like an intentional configuration step by AMD - for what reason, I don't know. If both the Intel and AMD versions use the same panel, I can't think of a reason why they'd need a different ICC profile? At this point, I think all we can say is, we correctly load the default monitor profile, and we correctly convert colours (as does Photoshop). From here, this is probably a bug for Microsoft or AMD to sort out (and for other similar scenarios - whoever made the ICC profile).