Interrupting, long loading on CMD + C (copy)

[unicon]

 

Hello everyone, ran into this many hundreds of times in the past months - since I'm using the product. Thought I might give sharing this here a try. 

1. Affinity Designer
2. Yes!
3. Yes! Every time!
4. It's slightly less when I copy the same content to a copy in fresh document, but still happens.
5. If you cannot provide a sample document then please give an accurate description of the problem for example it should include most of the following:

•    Ventura, M1 Max, 64GB of unified memory 2TB Storage
•    Acceleration ON
•    Long load on copy of relatively complex segments/objects of file
•    Reproduce: Select vector object, CMD + C, Multi second loading starts, app becomes unresponsive
•    Screenshots (very handy) or a screen capture/video.
•    No unusual hardware. Happens with normal MacBook Pro internal display as well as externals
•    Happens since a few months, nothing changed

I use rather complex vector graphics that I can not share due to a project not being finalised and releasable yet. However it should be reproducible with any rather complex vector object. I fully understand this may be due to technical limitations of the current implementation, however similarly complex vector files in illustrator do not show this strongly interruptive behaviour. It majorly slows down the flow of working with complex graphics.

copying_issue.afdesign

Edited July 21, 2023 by unicon

[walt.farrell]

Welcome to the Serif Affinity forums.

One question: is the issue with Cmd+V (which is Paste, usually) or with Copy (usually Cmd+C)? Your description seems to mix that up, making it less than clear when you're seeing the issue.

Also, if the problem "should be reproducible with any rather complex vector object" can you create such an object that is not related to your project, but which demonstrates the problem, and share that? The problem is that only you know what kind of complex object you're taking about, and if it happened easily more people would be complaining about issues.

Or, if Serif staff provide a private upload link so only they see your file, could you share the project for with them to enable diagnosis?

 

[unicon]

Hey Walt, thank you for a swift and warm welcome. It's true. In the hurry I mixed up CMD + C and V. I mean CMD + C. It only happens on the action of copying, once the object is copied, pasting is without any interruption.

 

Regarding the vector graphics: Understand it's nicer to reproduce this way. I attached an affinity designer file with one single artboard including some vectors. The content in this file does not include as many individual paths as the real ones, but it still happens for me. With this file, it's reproducible when copying the full art board.

copying_issue.afdesign

Edited July 21, 2023 by unicon

[MikeTO]

I'm using an M1 Pro, not an M1 Max, with Ventura 13.4.1 (a). I'm not able to replicate a delay when I press Cmd+C with the full artboard selected and I can immediately press Cmd+V without any perceptible delay. However, when I quit Designer with your artboard on the macOS pasteboard there is a long delay, about 14 seconds. This is presumably the same issue you're experiencing, just manifesting in a different way.

I took a look at the pasteboard with a utility and examined the four versions of the data on the pasteboard - this is normal, apps always copy multiple versions. Three of the four versions are tiny but the big one is a 51MB public PNG (14174 x 10063). I believe this is the issue. It takes about 14 seconds for the pasteboard viewer utility I used to display the PNG which might be a coincidence but unlike most apps, Affinity clears the public pasteboard when the app quits. If you're having a delay creating this on the pasteboard and I'm having a delay clearing the pasteboard, there's a chance it's related.

I don't know if this is an option for you, but changing the dpi from 600 to 300 cuts the delay by 75% for me which again makes sense as the generated PNG is then 25% of the size.

[unicon]

Hey Mike, 

Thanks for your answer, besides this issue, the pasteboard inspector is super interesting! What is it called? Also nice to learn that pasteboards copy multiple versions (for different purposes). Makes total sense!

The similar timing of ~14 seconds on closing Designer and opening the image in your inspector sounds like no coincidence indeed. Also a 14 000 pixel image definitely takes a toll, since I assume it has to be actually created from the raw vector data on the spot. However strange you can't reproduce the actual copying issue. Reducing the PPI is definitely an option, thanks! However would be very interesting to think of elegant universal fixes for this from dev side. What comes to mind is caching the png but that'd take tons of RAM - disabling specific pasteboard representations.

I'll try around and see if I can reach a state of the program where copying shows no loading behaviour, like in your case. If I manage that I'll check where the difference to my usual workflow is.

Is there anyone from the staff who can shed some light on how things are copied and where the bottleneck could be?

[MikeTO]

1 hour ago, unicon said:

Thanks for your answer, besides this issue, the pasteboard inspector is super interesting! What is it called? Also nice to learn that pasteboards copy multiple versions (for different purposes). Makes total sense!

The app I used is: https://apps.apple.com/us/app/pasteboard-viewer/id1499215709?mt=12

Viewing what's on the pasteboard with a utility can be confusing because this information isn't intended to be viewed by non-developers. There are public and private pasteboards - any app can access what's on a public pasteboard while only the app that created it can access what's on the private pasteboard. This is so that apps like Affinity can reference an internal copy of the data or in its own format to avoid losing custom data. Data is copied into multiple formats so that different apps are able to paste it. For example, a text editor might only be able to deal with plain text while a word processor could deal with RTF. Affinity creates a PNG in addition to other formats even for vector images because it can be used by almost any app.

[walt.farrell]

1 hour ago, unicon said:

Is there anyone from the staff who can shed some light on how things are copied and where the bottleneck could be?

They should be able to provide additional info, when your topic reaches the front of the queue. Note, too,  that evenings and weekends (UK time) have smaller staffing levels than at other times. But it can take a day or two even during the week, depending on what else is going on.

[Oufti]

On 7/22/2023 at 3:28 PM, unicon said:

However strange you can't reproduce the actual copying issue.

Here, there is indeed a visible interruption of service. 

What I did: Open the file, cmd-A, cmd-C.

It took enough time to notice it was interrupted, going to the Activity Monitor — where Memory and Process uses were not excessive (± 100 % CPU, when I can have ten times more, and green Memory pressure) — then (after 15-20 seconds) seeing for a while that Affinity Designer was not responding (written in red), then operating again (after a total of about 30 seconds). 

(My config is in my signature.)

Edited July 24, 2023 by Oufti
Precision

[unicon]

Hey @Oufti

wow, thanks for adding this behaviour to the list! Just tried CMD + A before copying, and indeed that loads even longer and completely brings the application to idle - even though the file includes only a single art board.

[Oufti]

But waiting enough (half a minute) and Designer resumes and works perfectly. It just stops a moment and then it's up again. 

[stokerg]

Hi @unicon,

I also wasn't able to replicate the coping delay on my M1 MacBook Air BUT I can replicate the closing delay.  I've logged it with the Developers and will create a separate one if needed once I've got someone with an M1 Pro or higher to test the copy+paste delay issue