Art51

This might be related to recently reported bug AF-7720 as you've reported problems saving and copying a pixel layer, slow performance and a crash. See the following thread: https://forum.affinity.serif.com/index.php?/topic/233294-photo-263-crash-and-report/#comment-1382376 As well as providing your systems specs it might be helpful for the Serif team to see a crash report and the steps that led to the problem.

Cheers @MEB

Thanks @NathanC !

Hey @MEB, I've attached a simplified version of the document with just the group that includes the affected pixel layer, named 'Lines'. To replicate the issue: Copy (Command C) the 'Lines' pixel layer and paste it (Command V) within the group Select both 'Lines' layers by holding Command and clicking Right-click and 'Merge Selected' (takes longer than usual) Select another layer, i.e. 'Paint', and try to paint on it by selecting a round soft brush and a colour. It won't paint or select the colour. The programme becomes unresponsive and unable to save requiring a Force Quit. I have duplicated and merged pixel layers in numerous groups in this document and others without issue, and so I'm unsure why this particular layer is not behaving. When the problem presented I was able to create a new document and copy and paste all my layers and groups into it and this has allowed me to continue to work. I have previously found that if I copied a pixel layer or group with pixel layers from a document created in Photo 2.5.x (i.e. something less than 2.6.x) into 2.6.x then that layer will experience painting lag and other function lethargy. As such, I will now only work with documents/layers that are created in 2.6.x Thanks for looking into it! Let me know if you need any other info. Test document.afphoto

This morning I've had to force quit Photo several times due to unresponsiveness following the merging of two pixel layers within a group. I have several groups of pixel layers with a document. In one of the groups I duplicated a pixel layer and then merged them both. The merge took quite some time and then the programme became unresponsive (unable to save) requiring me to force quit. I reset Affinity Photo settings and relaunched only to find the same issue. See attached crash report. I then turned Hardware Acceleration OFF and performed the merge. There was no unresponsiveness and I was able to save. This action hasn't been an issue up until today. I have been merging pixel layers without issue in 2.6.3 prior to today. Weird. 2019 MacBook Pro 16" i9 with AMD 5600M Ventura 13.7.4 Hardware Acceleration ON XP Pen Artist 24 drawing display as input device Crash 29 Jun 2025.rtf

No worries at all and thanks for sharing your thoughts. The feature works fine and I have been using it since it's introduction, however, it's 5 seconds after having used the feature that the Smudge brush reactivates without pressing the shortcut. That, specifically, is the bug. It affects no other shortcuts/tools. For example, when using the Paint brush tool and invoking the Erase shortcut there is no issue with Erase reactivating 5 seconds later. Hope that all makes sense.

Thanks for the reply, however I think you may be misunderstanding the feature that was introduced a little while ago in V2, i.e. holding a shortcut key to invoke another tool only whilst the shortcut key is held. Releasing the shortcut key returns to the original tool. Most usually one will be using the Paint Brush tool and will hold the 'E' key to erase only as long as 'E' is held. See the 'hint' at the following link under the heading Tool Shortcuts : https://affinity.help/photo2/en-US.lproj/index.html?page=pages/Workspace/shortcuts.html&title=Keyboard shortcuts Per the bug I've noted above, about 5 seconds after the shortcut key 'S' is released the Smudge brush reactivates with no shortcut key having been pressed.

Just a little bug. When using the Eraser tool I hold down the 'S' key to invoke the Smudge tool briefly. I then release the 'S' key and the tool returns to the Eraser as expected. However, after a few seconds (roughly 5 secs) the Smudge tool reactivates without any user input and makes itself the current tool. This requires me to tap 'E' to invoke the Eraser tool again. This occurs consistently and only when using the stylus on my XP Pen Artist 24 drawing display. This does not occur when using the mouse for input. MacOS Ventura 13.7.4 2019 Intel MacBook Pro 16" i9 with AMD 5600M XP Pen Artist 24 with latest driver. Hardware acceleration ON

@Chris B Just an update re the issue I had with playing MP3s whilst using Photo. As of v2.6.2 there is no longer an issue with my setup. I've just pressure-tested the programme with a big hand-drawn art project (7000x10000 px canvas with well over 100 layers including masks, blend modes, adjustment filters) and all ran super smooth. A great experience all round on my intel MacBook Pro! So a huge thank you to the team for all their great work. Photo is just a pleasure to use and serves my illustration needs wonderfully!

Just an update re the issue I had with playing MP3s whilst using Photo. As of v2.6.2 there is no longer an issue with my setup. I've just pressure-tested the programme with a big hand-drawn art project (7000x10000 px canvas with well over 100 layers including masks, blend modes, adjustment filters) and all ran super smooth. A great experience all round on my intel MacBook Pro!

Just an update re the issue I had with playing MP3s whilst using Photo. As of v2.6.2 there is no longer an issue with my setup. I've just pressure-tested the programme with a big hand-drawn art project (7000x10000 px canvas with well over 100 layers including masks, blend modes, adjustment filters) and all ran super smooth. A great experience all round on my intel MacBook Pro!

That's great to hear the SSD has worked wonders! Great stuff. PS- I must say the MP3 issue is no longer an issue with my setup and Affinity Photo 2.6.2. I've pressure-tested the programme with a big project and have had NO issues with lag or stalls at all. It's all running super smooth. A great experience all round on my intel MacBook Pro.

@jmwellbornThanks for the link and the solution. No doubt that will help others who are tearing hair out. I've not yet had the 'recent file' problem. Seems it might be something to do with Ventura 13.7.5 (I'm still on 13.7.4).

No, I haven't had any issues when using Mail. My problems (lags resulting in regular beachballs) arise from playing MP3's. I can't tell if this is related to the unusually high use of RAM by Affinity (the WindowServer process seems directly connected however). I haven't experienced the high RAM usage in other graphics programmes either. As a matter of interest I have saved files from Affinity as PSD's and opened them in other programmes such as Pixelmator Pro, PS and Krita and they don't exhibit the same high RAM usage, though it must be said the files don't export exactly true to the original either depending on whether a live filter is applied etc. so that might be where the RAM peaks arise specific to Affinity. Notably, all the other programmes redraw the screen (zooming and panning) much faster than Affinity, to the point it's not noticeable. My files are typically ~7000px X ~10000px with over 100 layers, so they are big to begin with. Interestingly, in Affinity I get slightly better, smoother performance panning, zooming, painting etc. when disabling Hardware Acceleration, but the trade off is reduced quality with some brushes whilst other brushes (those with sub-brushes) are terribly laggy to the point of being unusable. Hence, I keep Hardware Acceleration ON. Pixelmator Pro utilises Metal and has consistently great performance across the board regardless of file size. Krita doesn't use Metal (utilises OpenGL) and it too is fast and smooth. So something about Affinity offering both Metal and OpenGL causes vexed performance issues. All that said, I'm quite happy I've figured out a combination of settings (both Affinity and System settings) that afford me the performance I need to get my work done. It took way more than a usual amount of experimenting to get there and so I'm now loathe to change anything that upsets the balance! I've enrolled in the Beta programme so that I can test a new update before I instal it proper. This way I can make sure everything works okay before committing new work and old files to something that might not be backwards compatible should I need to downgrade for some reason.

I hope there is some combination there that might improve things. Also, I see that the WindowServer process was active at the time you were using Affinity. I've also noticed this at times. Not consistently, but every now and then and usually for a period soon after updating Affinity. It certainly causes my system to work overtime when using Affinity. I'm not really sure why WindowServer hogs so many system resources as it's function is to manage what is drawn on the screen. Perhaps there is something not quite right with how Affinity uses/redraws content displayed in the work area. It is certainly the interaction with Affinity that causes the process as closing Affinity rectifies the issue. Perhaps someone else might have some insight?

Hi @SKO, I'm on a similar system, MacOS Ventura 13.7.4 on 2019 Intel MacBook Pro with AMD Radeon Pro 5600M. I'm not sure why your thumbnail images in the Recent panel aren't showing up. But I can offer some suggestions for your performance/memory ills. Primarily, I find that playing MP3 music via the Music app or any other music programme whilst using Affinity Photo causes massive lag and and issues. It took me quite some time to figure out MP3's and Affinity Photo don't play well together. I haven't checked to see if this is the case when using Affinity Designer. Also, there can be issues around the Hardware Acceleration setting in Affinity>Settings>Performance. You might find turning it OFF will help matters. Personally, I leave it ON and make sure my OSX Automatic Graphics Switching is OFF, thus forcing the system to use my AMD graphics card and not the Intel integrated graphics. You can find OSX Automatic Graphics Switching in System Settings>Battery>Options I agree, the memory usage can seem inordinately high. My working files are larger than yours, but sometimes the memory usage does blow out so it can help to look at the other Affinity Performance settings: Make sure your RAM limit (and Disc Usage Warning) isn't set to use all the RAM your system has. My system as 32GB total, so I move the slider down to allow about 22GB which allows oodles for other system tasks etc. Consider lowering your Undo Limit as this will eat up memory if it's high. Try different View Quality settings. I use Bilinear and it works fine. You should be able to keep Dithering and Precise Clipping ON I keep my File Recovery at 300 seconds. Display is set to Metal (as I'm using Hardware Acceleration), but if you turn off Hardware Acceleration try it on OpenGL. Retina Rendering is set to Automatic which should be fine on your system too, but you can change it and experiment. I am also wary of upgrading OSX. I was perviously on Monterey and was having the MP3 issue with no solution offered by Affinity and so I eventually upgraded to Ventura hoping that the new Metal 3 would fix some performance issues as it is the same version run by current OS's. Unfortunately it didn't. That said, now that I know where the quirks and idiosyncrasies lie I can adjust my settings, play music on my stereo and enjoy great performance with Affinity on my Intel MacBook Pro. Equally, you should be able to have a great experience on your system too. The recent Affinity 2.6.2 update fixed some buggy app-specific issues that were quite vexing, and hopefully more fixes are on the way.

Thank you!

A mobile camera video (as opposed to a screen recording) of your screen which includes your stylus and use gesture would be helpful in order to explore how the above example can be replicated. Also, it is difficult to discern from the videos above what resolution you're working at and how large the brush is in relation. Specifically, when tilting, is the brush growing from small to (relatively) very large?

That's great to read your original artefact bugs have also been fixed. Regarding the tool as it is now, I'm able to achieve a wide range of smudge strength and nuance with the various settings now the edit panel bugs have been resolved. Hopefully there's nothing I've overlooked in my testing. I've made a new bug report for the small issue I noted in my post above (the 3rd video in the post with three video examples).

A minor bug. If I use a mouse as my input device, the smudge brush seems to sample and stamp colour (or transparency in transparent areas) when single-clicking with the mouse. Note, however, if the mouse button is held in and the brush is dragged then the colour stamp does not appear. This single-click behaviour doesn't occur with my drawing display and stylus. See video using the mouse below: Smudgestamp262Beta3213.mp4.2baf394c088f01688c808be10b8def63.mp4 2019 i9 MacBook Pro 16" with AMD 5600M and Ventura 13.7.4 with Hardware acceleration ON.

No worries @JaneV. I thought it might pay to check. As you can see, my experience (with a round soft brush) is the equal opposite of yours. As demonstrated, my exact same settings behave in exactly the same way. Perhaps there might be an issue with specific brushes when used as the Smudge tool? This has been raised already. I'd be interested to know how @Chris B was able to confirm your experience when you didn't provide details of the brush you used, whether you're using a mouse or stylus, your OS, hardware acceleration settings etc. and so how he was able to replicate your anomaly and able to provide the developers details. Perhaps there is something other users - like myself - aren't investigating in relation to systems and/or settings. Maybe someone else will chime in with their findings and shed light on the matter. As noted in my other posts re the Smudge Tool, my system is: 2019 i9 MacBook Pro 16" with AMD 5600M and Ventura 13.7.4 with Hardware acceleration ON. XP Pen Artist 24 QHD as input device.

@JaneV @Chris B Just wondering, are you certain your brush settings were exactly the same as in 2.5? I only ask as I've also rolled back to 2.5.7 because of this and a few other bugs and when I installed the new 2.6.2 Beta 3213 I noticed the settings of my favourite smudge brush had changed a little. When I modified them to match the ones in 2.5.7 I'm getting the same results in both. By my estimation and experimentation, this Beta has fixed the anomaly I was experiencing, i.e. forced spacing and too much 'strength', and returned my brush to its previous expected behaviour. For those folk wanting a stronger smudge as 2.6.0 introduced, they can do so by modifying their settings, namely spacing and strength. Note, I'm using a drawing display with stylus as my input device. Below is a comparison of the exact same brush settings in 2.5.7 and Beta 2.6.2 (3213). 2.5.7: Smudge 257.mp4 262 (3213): Smudge 262 Beta 3213.mp4 Unfortunately, I have found a bug (that was briefly mentioned by @paolo.limoncelli earlier) in that if I use a mouse as my input device then the smudge brush seems to sample and stamp colour (or transparency in transparent areas) when single-clicking with the mouse. Note, however, if the mouse button is held in and the brush is dragged then the colour does not transfer. This single-click behaviour doesn't occur with my drawing display and stylus. See video using the mouse below: Smudge stamp 262 Beta 3213.mp4

Thanks for looking into it @NathanC!

Cheers @NathanC!

There seems to be something amiss in the brush engine with regard to tilt. In the post I made above regarding the artefacts in the pencil brushes, it concerns the brush being used with tilt (causing the brush stroke to increase in diameter). The artefacts don't appear when tilt isn't employed. Also, in that example, the artefacts don't appear when hardware acceleration is on.