danmerey

Yeah, please think about Windows users. At least give us possibilty to swap Right Mouse Button and Shift behaviour or rebind it for Selection. Because I don't really use shift that much in Affinity, though Right Mouse Button for adding selection is super weird and unnatural. Also yeah, it's frustrating that I can't add selection with my Wacom.

Yeah, please think about Windows users. At least give us possibilty to swap Right Mouse Button and Shift behaviour or rebind it for Selection. Because I don't really use shift that much in Affinity, though Right Mouse Button for adding selection is super weird and unnatural. Also yeah, it's frustrating that I can't add selection with my Wacom.

Yeah, please think about Windows users. At least give us possibilty to swap Right Mouse Button and Shift behaviour or rebind it for Selection. Because I don't really use shift that much in Affinity, though Right Mouse Button for adding selection is super weird and unnatural. Also yeah, it's frustrating that I can't add selection with my Wacom.

We are aware of an issue with copying layer effects from one object to another and it not keeping the original settings and it's logged with the developers.

I've followed this topic since my last post because checking/unchecking "Force pixel alignment" and "Move by whole pixels" certainly did not solve this problem and I've lost hours of work myself noticing too late that my merged layer has been blurred. I really admire you advanced users for your patience taking the time and effort to investigate, doing your homework to find out how and when the blurring happens, how to work around and sharing all these results.
The ignorance of Affinity Developers frustrates me also. I imagine if I delivered work to my customers with such "anti-aliased" line-art, trying to explain to them that the file was a perfectly healthy, high quality image, not corrupted or blurred just anti-aliased which is perfectly normal, they wouldn't be very happy with me... so instead I calmed down, did the lost work again and delivered a quality file as expected of me. I would expect a similar professional behaviour from developers. Bug or not bug, this blurring has no place in Affinity Photo which is supposed to be an intuitive program, behaving as expected, that lets you concentrate on creative work instead of worrying all the time trying to notice the moment your layer goes corrupted/blurred.

There's no way "it's inherent in the document itself", since just applying a rasterize operation on the bottom layer you're about to merge before merging leads to the perfect and expected (and logical) result for most of us. A result without any blur.
Rasterize bottom pixel layer and then merge layers => perfect result. Merging didn't affect the quality of the data (as does PS). Before and after the whole operation (rasterize+merge), you got visually  strictly the same result.   Directly merge the layers =>  the content of both initial layers are blurred. From the beginning of this thread, I don't understand how this simple fact can be ignored. Maybe it's due to langage (english is not my natural langage and there's no doubt some of my sentences are incomprehensible). Maybe we didn't deal strictly of the same subject :
Maybe some got in mind the case when merging deals with non-pixel layers. In this case, yes, data of the non-pixel layer is necessarily affected due to the rasterization of its content before merging. No problem with that. It's logic. It's not what this thread is dealing about (it's dealt with pixel layers, normal blending, full opacity ).
And maybe there's a difference between the rendering of a pixel layer whom the content had be transformed before and after it's rasterization (in this case, rasterization (not a real-time operation) should logically lead to a better result (i.e less blurred), cos it can use more complexe algorithms) [to my experience : the result are strictly the same. Besides, the free wrap function which is far more complexe forces the user to commit its transformation. Which leads to think that for other transformations, the application achieve to comput and display the same image before and after rasterization]
But, considering the bullet points above, no acceptable justification had been given so far (I don't say there's none ... I'm neither an expert, neither a professional user).
So far it's a bug (unless there's hidden interest). And there's an alternative way to achieve the logical result that people who opened this thread expected (green bullet point above).
Those peoples, as myself, simply would like the application to produce nominally the result achieve  with this alternative process. Who wanted to get a blurred image when merging when it's easily  possible to get the perfect one (one line of code maybe) ? What the use ? Where's the gain ? If there's a gain, that what this post should eventually deal with now.
  

I started a new topic, since this one is pretty old and being ignored for a long time by Affinity Developers. If you have something to add, you are welcome. I also found an easy solution for Developers and one of the reasons, why this happens