Gabe

Hi @User123, Have you got a document that has this issue?

Hi @cur, Welcome to the forums. This is more of an improvement request. If you attach your ahk file, i can pass this on

Hi @beefer7, Welcome to the forums. Is this document specific? or a general issue?

Hi both, This is actually caused by having Display : Metal in Preferences > Performance (and not new to the beta). The hardware is not relevant. I'll get this issue updated.

You can replicate this very easily by creating a new document > place a large rectangle over the whole canvas (any colour but white or black) > Filers > Colour > Halftone. Set a small cell size (3px) and zoom in/out. You will see the appearance changes.

Thanks. It doesn't change opacity. What you see it's more/less similar to the moire pattern.

Hi @drswoboda, Can you use this link to upload the file in question? https://www.dropbox.com/request/mb2PMbkkvix2NCL3YvVV

Hi @Chamaco, Welcome to the forums Can you attach the afphoto file in question?

Hi @Lloydi, Welcome to the forums We are aware of this and it has already been logged with our developers.

I will pop this over to feature requests; the way it works at the moment is expected. Changing this to the way you expect it to work will break everyone's already existing documents.

Hi @Stocker.jp, Thanks. I've passed these on.

Well, you don't get the same results. In 32bit, creating a mask(with a gradient white to black) gives the exact same result as copying it from the 8bit doc. Screen Recording 2021-05-25 at 11.11.01.mov

Hi both, Thanks for spotting this. Issue logged.

A mask is essentially a layer, which still has "color data" (though it being R=G=B). Why shouldn't this be affected by the linear space? FWIW Photoshop does the exact same thing.

Hi @IPv6, RGBA/32 is a linear space, whereas 8/16 are not. So this is expected.

Hi @dmstraker, So that we are able to investigate bugs thoroughly could you please follow this link and update this post with the followings: https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/

Hi @thomaso, Thanks. We are aware of this and it has already been logged with our developers.

Hi both, This is not hardware related. When you undo, you're removing that pixel layer you're currently drawing on (while still drawing). Generally it's not a good idea to undo/redo while you are doing something else…. Surely the app should not crash, but what did you expect to happen when you hit undo while still drawing? Issue logged.

Hi @Richard Mlynarik, Thanks for spotting this. Issue logged.

Hi @patricia1, So that we are able to investigate bugs thoroughly could you please follow this link and update this post with the followings: https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/

The Appearance stoke not matching the correct stroke value if Scale with object was ticked was already logged with our developers. I was only saying the original recipe/steps(1st post here) to replicate the issue did not say to scale the object, so that's why I've asked for a screen recording

Thanks. This seems to be caused by having a corner on a node that shouldn't be possible to have a corner on. I'm afraid we don't have a recipe to replicate it or suggest things to avoid it . Technically, it could happen again(before we fix it), but it is quite unlikely.

It is indeed caused by scaling and having "Scale with object" ticket (neither of these were in the original recipe though).

Hi @0o_bow_o0 Sorry for the delayed reply. you could try and go down the iMazing route and see if you can recover any files:

Thanks for raising this issue - we have closed it as "By design".