Jump to content
You must now use your email address to sign in [click for more info] ×

Paste, duplicate and arrange get slower as document increases


Recommended Posts

I'm putting Publisher on hard work with a catalogue with around 2000 images. So far, i'm in love with the experience, swiftness and smoothness of the process.

But there are four actions, very recurrent that are getting me nuts.

  • Pasting anything just copied from the document
  • Duplicating elements with alt+drag
  • Arranging objets up and down layers
  • Deleting an object

Each time i do any of this actions, it take up to five seconds of non-responsiveness even with a second or two of beachball of death in the cursor. The curious thing is that this only happens when you do it AFTER any other action. Once you duplicate, paste, delete or rearrange, you can do it again with no lag immediately after. But do any other action (write, draw, move…) and the lag behavior returns next time you do a duplication, pasting, deleting, or arranging. 

Also, it doesn't matter what the object is. It can be a simple text frame with two letters, a heavy image or a single square. Is as if Publisher where loading something or writing on disk. And the lag gets bigger as document size increases. Having in mind that this are basic recurrent actions, the lag is a bit nerve breaking.

Behavior does not disappear restarting the app or the whole system. On new documents with few content it works perfect. Maybe a RAM issue?

I did not appreciate this until 1.8.4 (But it could be that the document has become bigger after upgrading. Already tried saving to a new document to prevent file corruption)

Publisher 1.8.4
Catalina 10.15.6
24 GB Ram
4050 gb free disk space

Link to comment
Share on other sites

Hi @Jon P

All images are JPG linked. The thing is that the app does not have any issues moving all those images, navigating, editing, etc. The fails are in those simple actions mentioned, and only those, and once you do the action, you can redo it again with no lag, until you do a different one. Is as if publisher where loading the action slowly but once loaded can use it.

Apart from this, Publisher has been doing it like a champion. This same catalog was done before on InDesign and the improvement is great. (job not imported from ID, was layout from scratch)

I've been monitoring Activity monitor and the app has free RAM available, never reaching the settings marked limit (Computer has 24 gb of RAM) but I've noticed that just opened only use 1 to 3 gb, increasing as I work to around 12/13 gb peaks. But when you closed the document it get stuck on the RAM used while working, as if Publisher failed to release the unused RAM.

I don't know it this helps, but let me know anything I can do for you

Link to comment
Share on other sites

  • Staff
Quote

The fails are in those simple actions mentioned, and only those, and once you do the action, you can redo it again with no lag, until you do a different one. Is as if publisher where loading the action slowly but once loaded can use it.

I'd be interested to see if I could reproduce this, do you think it would be possible to upload the file and all linked resources (or maybe change them all to embedded and send it if that is easier?). You can use this link i'f it's possible!

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

  • 5 months later...
On 8/17/2020 at 12:06 PM, Jon P said:

I'd be interested to see if I could reproduce this, do you think it would be possible to upload the file and all linked resources (or maybe change them all to embedded and send it if that is easier?). You can use this link i'f it's possible!

Hi Jon. I'm sorry for the long long long delay answering. I finally got authorization from our customer to send you files (there was confidentiality clause over it). We have been having the same issue with other projects and the issue is still present on Publisher 1.9

Is the Dropbox link for uploading still available or do we need a new one?

Also, for your commodity, here is the list of actions that got slow:

  • Duplicating object (both command+j or Alt-Drag)
  • Pasting object (It does not happens with text, only with objects)
  • Changing layer order on an object
  • Moving object to another spread

Also, as I told you before, it happens once and then you can repeat the action with no issues. It re-happens again after you do a couple of different actions. Any other action works perfectly (Rendering, moving, layout, adding pages, navigating on the document, adding images, changing text…) Is for this that I don't think is a lack of memory but a fail managing or loading actions to the memory, as is not application wide slowering.

Also we have tested it on an M1 mac so we can confirm that the issue is not intel related, and also tested it on two more macs.

Let me know if you are still interested on the issue and the link is still available.

Link to comment
Share on other sites

  • 1 month later...

Hi again, @Jon P

We have been researching on the issue and we think we have framed the cause and why it happens.

First, the files are in a NAS server, so the read speed is slower than from local HD (Despite gigabit ethernet, but crappy Apple's SMB implementation).

Second, the lag is produced each time we do something that changes the number or disposition of layers in the current spread. (so it is because of this that only happens on duplicating, rearranging order, pasting and moving from other spread)

After testing against a local copy (which causes no issues), we have come to the conclusion that Publisher does an excessive reload/re-read of linked files each time we do those actions. As the network can't offer fast enough speed, publisher gets beachballed until it reads the linked files and let us to continue. Also this explains why we can work normally after that (The images are checked and it does not re-load them until we do other of the "evil" actions again).

We don't know why Publisher needs to reload the linked files so often (We tried disabling image autoupdate in preferences with no luck). But is clear that is image reload (or re-read, or checking) that causes it. It does not explain why it happens on documents with big number of images, ¿Maybe Publisher checks all linked images each time we modify layers in a spread, instead of checking only the images in that spread?

After much testing, what we are sure is that Publisher does not have issues managing documents with thousand of images (It moves the document smoothly and if you don't do layer altering actions it works superb) , but it does have problems with excesive read/checking images in those cases mentioned.

Bad luck for us, we can't get rid of the server and work in local disks, we need to do team work. I hope this info could be useful for you. Let us know if we can help with more info or testing.

 

Link to comment
Share on other sites

On 8/14/2020 at 11:50 AM, Jon P said:

we are looking to make some improvements in image heavy documents.

@Jon P,  good idea! How about an additional Preview Mode in a lower resolution? It could be less demanding for redraw/rendering and might even ignore resource links until high-res preview mode gets selected or a resource gets altered.

@Daniel Gibert, in a very early APub version I noticed that reducing the document resolution could increase the working speed (and also reduced the .afpub size on disk, I assume because of different preview file size). I did not notice any harm when I then reset the document resolution later back to its initial high resolution. – So, it might be worth a trial in case there is no resolution relevant layout option used (e.g. layer rasterization).

19 hours ago, Daniel Gibert said:

We don't know why Publisher needs to reload the linked files so often (We tried disabling image autoupdate in preferences with no luck)

One irritation might be caused by APub's feature to check for missing resources permanently, regardless of the auto-update setting. I would not expect this behaviour but it might be desired when resources aren't stored locally to get informed immediately if a related disk isn't available any more. However, that would not explain unexpected re-loads of resources.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.