Issue:
When running InCopy 2 in story view on Mac OS 10.x, if the user switches to another application, CPU use jumps to 100%

Solutions:
1. Switch to Layout or Galley view before sending InCopy to the background.
2. Minimize the document window or application before switching applications.
3. When the application is sent to the background, set the flag to allow layout composition to occur. When switching back to the front application, restore the previous state of the flag.

Note: Access to the flag is available in ITextLines. A method called SetComposeLayout() controls it. Don't forget to restore it or story view performance will suffer.

Additional Information:
InCopy composes text to the window bounds in story view, however the text still exists in text frames. So, composition also needs to occur for the layout. While in story view InCopy ignores layout composition (there are some exceptions). Layout composition is suppressed because it effects performance in story view and leads to a more sluggish editing experience.

There is an idle time task that layout uses to perform composition. This is normally suppressed by story view. However, in this case where the application is not frontmost InCopy does not suppress it fully and is trying to recompose. If it were allowed to complete it would do it's composition and never try again. However, it is only partially active so, although it starts to recompose, it doesn't finish and this causes it to try again a short while later (and again, and again). This leads InCopy to claim more and more of the available CPU power.

There is a flag that controls the suppression of layout composition (ITextLines::SetComposeLayout() sets it). One solution is to get that interface and call SetComposeLayout(kTrue) when the application goes into the background to allow layout composition to complete. Then to call SetComposeLayout(kFalse) when InCopy is returned to the foreground in order to keep story performance from being effected.

Was this Knowledgebase document helpful? Yes  No