Designer unresponsive with PSD files

[kwaku]

I shared about this with 1.10 update with no response. I have updated to 1.10.1 and problem still persist.

Whenever I open PSD mockups files, Affinity Designer gets extremely slow and makes the application unresponsive. Would appreciate if this issue is resolved.

Using iMac (Retina 5K, 27-inch, 2017)  BigSur 11.2

[Hangman]

@kwaku I think your post got burried in the OP's thread pertaining to a different issue in that post.

Are you able upload one of the sample PSD mockup files you are having issues with so we can take a look to see if we can identify the cause of the problem?

[kwaku]

@Hangman

I appreciate the response. Find attached the file.

Childrens_Book_Mockup_1.psd.zip

[SPaceBar]

Hi @kwaku Thanks for the file. I've been unable to reproduce this on my iMac (Retina 5K, 27 inch, 2019) Big Sur or my iMac (27-inch, late 2017) Sierra. Could you perhaps take a screenshot of the Performance Preferences on your iMac please?

Go to Affinity Designer > Preferences > Performance

[kwaku]

@SPaceBar

Here is the attached screenshot.

[kwaku]

@SPaceBar any update on this?

[SPaceBar]

Hi @kwaku Your settings are the same as mine and even the hardware is similar. Is it only PSD files you are having problems with?

[kwaku]

@SPaceBar Only PSD files. 

[Hangman]

@SPaceBar I would have to agree with @kwaku, editing the PSD Mockup is like swimming through treacle, screen re-draw is relatively painful with text entry taking 2 to 3 seconds to update and screen re-draw very jerky (certainly nothing approaching 60 fps). I've experienced this with numerous mockups using Smart Objects. It's a little better in 1.10 than it is in 1.7.3 (which is almost unusable) for editing these mockups.

It seems marginally better without Metal Compute enabled but it's not great with either.

Did you try editing the any of the smart objects, e.g., the book cover on the sample @kwaku provided?

[kwaku]

@Hangman 1.9 was not too bad for me, it was slow, but I was able to work with it. Working with a smart psd file (mockups specifically) 1.10 rather makes the application unresponsive and I have to 'force quit' all the time.

What I have realized, If i open and save the psd as affinity design file (though it takes forever for the file to save) It works faster when it is saved as affinity file.

So that tells me there is an issue with psd files.

[SPaceBar]

@kwaku Would you be able to upload a video of the steps you need to take to make it unresponsive. It might just be that what I am doing isn't too taxing.

[Hangman]

15 minutes ago, kwaku said:

What I have realized, If i open and save the psd as affinity design file (though it takes forever for the file to save) It works faster when it is saved as affinity file.

It is taking less than a second to re-save as both an Affinity Designer or Affinity Photo file so I'm not experiencing that issue but it isn't making much difference in editing terms, for me at aleast, i.e., the screen redraw is still quite slow.

[MEB]

It's slow for me as well. Zooming to around 400% and panning is enough to make Designer struggle, specially if you keep moving the document. Reordering layers (embedded documents) does cause a slowdown and sometimes stop responding for one second or two i guess because most of them have perspective live filters attached. Also the file is not being properly imported. Some layers should be clipped but they aren't.

[kwaku]

@SPaceBar You can see how slow it is when working with the layers and it eventually became unresponsive. Working with PSD mockup files now are a pain to deal with.

[kwaku]

Any update on this? this problem cuts across most psd files. It also affects and crashes Affinity Photo. I just tried working on the attached PSD file and it constantly crashes both designer and photo. I do understand not every feature is supported in Affinity but each time one opens a psd file and the app crashes. That is unbearable. I  I have made the switch to Affinity and I still have tons of psd files to work with. Is affinity doing this to discourage users from using PSD files?

 

Long Shadow Fade Bottom Left.psd

[Hangman]

@kwaku There appears to be a couple of issues with the way both Photo and Designer are handling your attached file despite the file being fundamentally very simple. Both fail to read the embedded text file correctly resulting in the embedded text file showing with 0 kB.Even replacing the embedded text file with a version created in Affinity Photo results in a file which is very slow to render because Affinity Photo and Designer appear to struggle or run out of memory.

@MEB and @Sean P Would it not make sense when using the Resource Manager to replace files to include an option when selecting Replace that gives the user the option to replace just the selected instance of the file or all instances of the file. The same identical text layer in @kwaku's file appears 402 times and it can currently only be replaced one instance at a time which is painful since it means having to repeat the Replace process 402 times. Selecting all instances of the embedded file in Resource Manager greys out the Replace button.

Opening the file in both Affinity Designer and Photo after having replaced all instances of the embedded text file with an Affinity Photo version displays the embedded file correctly in Resource Manager (see above image) but seems to require a huge amount of memory to open and render. Opening the file using a Mac with 16Gb Ram and 18Gb of HD space in both Affinity Designer and Photo fails to render (for me at least) all instances of the font used for the 'Shadow Text' resulting in this...

Basically even with that amount of memory the font fails to render at a certain point in the layers panel, I assume because it runs out of memory...

Freeing up some HD space so there is now 27GB free does allow the file to render correctly, albeit painfully slowly, but should it really require that amount of virtual memory in addition to the RAM?

The other 'issue' when opening the source PSD file is that the PSD Gradient Overlay fx isn't rendered correctly in Affinity Designer or Photo, it should appear as per the left image but instead appears as per the image on the right. Affinity Designer and Photo are ignoring the Offset X: and Y: values from the PSD Gradient Overlay and resetting their values to 0% meaning they need to be manually adjusted to achieve the correct gradient fall off.

Also, exporting the re-engineered file which is now 100% Affinity as a PSD file then changes the values used for the Gradient Overlay fx from those on the left to those on the right, so they have to be manually adjusted to achieve the correct effect, though correcting the values and re-exporting to PSD resets the Scale X: and Scale Y: values back to 1% each again, regardless of whether Scale with Object is selected or not.

For reference, the font used is Bebas Neue Regular which is free to download from Google Fonts.

Long Shadow Fade Bottom Left (New).afphoto

Embedded File - Long Shadow.afphoto

Long Shadow Fade Bottom Left (New).psd

[SPaceBar]

@kwaku & @Hangman That second document was definitely slow to render for me and when viewing the resource manager it became unresponsive. This looks to be down to the amount of layers using the layer effect. The Smart Object option in Preferences is disabled by default and once I enabled that and the option to "Import PSD text as text rather than bitmap" it improved. It also allowed the PSD to function as intended and update the drop shadow. I then modified it to add my own text as intended and the lag I previously saw when viewing the resource manager was gone too.

The performance you're seeing is certainly not intentional to discourage the use of PSDs, but as the feature sets aren't 1:1 you can't always map them easily from one application to the other so you may get some things perform worse than others. In this case the 402 pixel layers (if you didn't enable Import PSD Smart objects as Smart objectS) was likely causing the memory to struggle in some places.

@Hangman, with regards to the 0kb showing up, we're not entirely sure why, but suspect it's likely related to it coming from a PSD Smart Object where the file size is not logged. However, I will get the Gradient Overlay position looked at as I can see that with just a single layer.

[Hangman]

@SPaceBar I had both 'Import PSD text as text rather than bitmap' and 'Import PSD objects where possible' enabled when opening @kwaku's second file, so the text layers were imported as PSD Smart Objects using live text but it was painfully slow to render and as mentioned initially failed to render even with 18Gb of virtual memory. After replacing all 402 instances of the text layer, things did improve a little but again still very slow to render the whole screen.

I guess the question is should a large number of layers using an fx cause such a drag on rendering, especially since it was applied to the group rather than individually layer by layer.

Could I add a feature request for the Resource Manager so that it is possible when selecting Replace to include a feature that gives the user the option to replace either just the selected instance of the file or all instances of the file. I had to manually replace all 402 instances of the text file one by one despite all instances being the same identical file, it would have been great to just select Replace, select the first instance and then be presented with the option 'Would you like to replace all instances of this file?' and then Yes or No.

 

[kwaku]

@Hangman Not in tune with the engineering aspects of things. Now working on PSD files are a gamble. it will either work smoothly or it will be slow and crash the app.

I just hope this is resolved. One big win for Affinity applications, you can create original files and work with psd, ai files. That is the biggest move that motivates people to actually transition to Affinity. Now if we have this slow, crashing, situation when working with psd, files, that is going to be a big loss for Affinity. I love Affinity and what it represents and its potential. Its the 'little things' like this that matter.