Low performance in a big document

[Herojas93]

   Hi guys,

Actually I’m working on a manual that has 222 pages. My Mac is a MacBook PRO 15” Late 2013.

It is A4, 800 dpi (I need people can do zooming without lose resolution) and the 15  images it has are all embedded , sorry, linked. The rest of items inside are 100% vectors with effects, like shadows, transparency, etc...

Metal is enabled.

I have extrematelly low performance in the document. When I do a change I have to wait about 30 seconds seeing the beach ball running until it is applied.

What can I do?

Thanks

[Hangman]

Hi Herojas93,

My first thought is that I'm unsure why you would need an 800dpi document, more so if the document is only being viewed onscreen, a 72dpi document would suffice and would make no difference to your image quality in that a 72ppi image will look identical to an 800ppi image with the same pixel dimensions when viewed onscreen and by their very nature, your vector images will be unaffected by the level of zoom.

If however the document is ultimately also going to be printed then the standard 300dpi format should be sufficient.

With regards your low-performance issue have you tried disabling metal to see if that makes any difference? There have been numerous bug reports in the forum talking about issues with metal which I believe the dev team are looking into. I'm unsure if this is the cause of your particular issue but worth a go to see if it makes any difference maybe.

[thomaso]

On 7/25/2019 at 8:23 PM, Herojas93 said:

It is A4, 800 dpi

Ignore document resolution unless you rasterize any object.

It is sufficient to set resolution for linked/embedded/vector content on export in the export settings.

Do not embed image resources.
Do not link to resources in a network or a cloud.

Do not export in a higher resolution than your lowest value of resource > placed DPI.

On 7/25/2019 at 8:23 PM, Herojas93 said:

I have extrematelly low performance in the document. When I do a change I have to wait about 30 seconds seeing the beach ball running until it is applied.

Watch Activity Monitor / CPU + RAM

Close other documents.

Close other applications.

On 7/25/2019 at 8:23 PM, Herojas93 said:

What can I do?

Give more information.

Upload your file(s).

[Herojas93]

Hi,

Following thomaso advices I expose my results:

1. The document resolution has changed to 72 dpi. (Still same performance)
2. All images are linked.
3. All images are store locally.
4. Only this document is opened.
5. Only publisher is opened. Any other app.
6. I tried changing the API from Metal to OpenGL with same results.

When I open the document the fan inside my Mac starts running and the Activity monitor shows this

In the moment I closed the 222 pages document everything goes to normal and fans becomes off.

Could be the optimization of macOS Catalina. Actually I'm using beta 5.

[thomaso]

1 hour ago, Herojas93 said:

When I open the document the fan inside my Mac starts running and the Activity monitor shows this  (...) 
In the moment I closed the 222 pages document everything goes to normal and fans becomes off.

Does it mean the increased CPU + fan usage remains all the time when the document is opened? Regardless of your actions with the document?

Could you also show the Memory section in Activity Monitor, please? It will be more interesting/meaningful if you do the screenshot after working in AfPub for 30 minutes.
(If you avoid working in AfPub then you could at least have it opened when doing other things on your computer for 30 minutes?)

1 hour ago, Herojas93 said:

Could be the optimization of macOS Catalina. Actually I'm using beta 5. 

Can you alternatively boot your mac in a former, non-beta macOS to see if AfPub behaves different relating your issues?

What happens if you work in other .afpub documents? Same occurrence, even with smaller files?

[Herojas93]

After work 2 weeks with that large document (220 pages, 72 dpi and linked images) I have notice that the big lag of performance appears when I work with fonts (text).

For example, I can copy, paste , move, objects and every time I can see the beach ball about 3 seconds until the system refresh. No problem with this.

When I edit, change, modify or similar any text, the beach ball takes around 20 seconds every modification I do.

Another example, if I select a text and I select directly from the panel a text style it takes around 3 seconds to refresh but if I select the same text and I go to the fonts menu trying to select any of them it takes around 20 seconds to refresh. Also if I don't select the fonts list (that maybe it has to preview), just changing bold, light, or the font size. 

Hope this could help to improve a GREAT app even more.

Thanks

[walt.farrell]

There are text-based operations that can take a significant amount of time.

For example, if you were to make some text bold, its width will be affected, which may cause that text (and all following text up to some point) to be re-justified and reflowed, possibly even adjusting text between linked text frames.

That may not be too complex, but it will be more complex if Publisher has to account for flowing the text around objects, and especially if you use complicated wrap outlines (or objects with odd shapes).

Changing the font would change both the width and height of text, and probably the leading, which will involve further calculations and effort reflowing the text.

Without having a copy of your file it would be difficult to provide more concrete examples or suggestions. I'm a bit surprised that moving the objects performs better than modifying the text, unless those changes have a more localized effect to the text layout.

[thomaso]

Also text based, additional/optional tasks, running in the background, is spell check / check spelling while typing. Though I haven't experienced a speed influence you could try to, if activated, disable those for a test from the menu Text:

The Text wrap menu item appears to enable one to set text wrap to off in general: "Ignore Text Wraps" – but, unfortunately, though a ticked item looks "as if", it indeed has an affect only for new or selected frames.

• How about your macOS beta? Have you tried to open/work your .afpub in a non-beta macOS?

• Also you could give some information as screenshot from the Activity Monitor.app > CPU > sorted by %CPU, to possibly see what process is demanding CPU while you are forced to wait. And, if there is nothing unusual occurring, a screenshot from the RAM/memory section: does the graphic diagram show green only when waiting or is it yellow or red?

• Last but not least: does the delay occur only in this particular .afpup – or in every document with more or less text?

 

[Herojas93]

Sorry guys for the late replay.

 

Disabling everything you mention before doesn't change anything.

I have found 2 things.

Everything that needs a live preview of changes like, font selection, color selection from wheel, text changing, ... decreases considerately the performance with big documents.

I have recoded 2 videos:

• 1 of them showing how much time takes the action of manipulate fonts.
• 2 video showing how copying and paste an object works relatively fine but copying the same object using option key (I think due the live preview of it) takes much more time.

Also I have attach a capture of the activity monitor showing the great amount of resources Affinity takes only with those kind of modifications. Another ones like vector lines, object movements, ... shows a normal Activity with the software.

 

Finally I can tell you that this only happens with big documents, even set with linked images and 72 dpi's, with small documents everything works fast and fine.

 

Thanks