Daniel Gibert Posted August 10, 2020 Share Posted August 10, 2020 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 Quote Link to comment Share on other sites More sharing options...
Staff Jon P Posted August 14, 2020 Staff Share Posted August 14, 2020 With 2000 images there will be a fair strain on the system, we are looking to make some improvements in image heavy documents. Are all the images linked or embedded? Quote Serif Europe Ltd. - www.serif.com Link to comment Share on other sites More sharing options...
Daniel Gibert Posted August 15, 2020 Author Share Posted August 15, 2020 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 Quote Link to comment Share on other sites More sharing options...
Staff Jon P Posted August 17, 2020 Staff Share Posted August 17, 2020 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! Quote Serif Europe Ltd. - www.serif.com Link to comment Share on other sites More sharing options...
Daniel Gibert Posted February 4, 2021 Author Share Posted February 4, 2021 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. Quote Link to comment Share on other sites More sharing options...
Daniel Gibert Posted March 13, 2021 Author Share Posted March 13, 2021 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. Old Bruce 1 Quote Link to comment Share on other sites More sharing options...
thomaso Posted March 14, 2021 Share Posted March 14, 2021 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. Quote macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1 Link to comment Share on other sites More sharing options...
Recommended Posts
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.