Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=NFR_TEXT_PERFORMANCE_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

Operations over text are currently very slow. These include:

• Operations with text frames (with some text in it, not empty) - rotate, move, zOrder change, insert, delete, resize, etc.
• Pasting of large text resources in text frames (10000 words, for example) as well as writing in frames with large texts. These are both modification of the text resource.
• All the above mentioned operations over chained frames are even slower.
• Auto-chaining is extremely slow.
• Saving / loading a book with large texts.
• A large quantity of small text resources (for example, 100 pages with text frames in them, each of them having a page of text).

Task requirements

• Make creation of a text layout faster. Currently it does not re-use previous layouts. It even has a lots of unneccessary calculations in it which slows down the layout a lot (Hint: createLineBreakMeasurer()).
• Make auto chaining process faster. It will certainly become much faster with introducing the layout reusage, but the algorithm of auto chaining is not quite effective anyway.
• Inspect and try to optimize the overall performance with lots of text resources. Currently, a book with 100 pages of text (even not chained) in totally unusable.

Task result

Significantly faster operations (modify, rotate, resize, reflow, move, and others) over normal and chained text. Fast auto-chaining process.

Implementation idea

After a prototypical optimizaitons in layout re-usage, it was noticed that chaining of 100 pages of text is still slow. The reason (this time) was not in the layout, but in the creation of the 100th page with the 100th frame in it. This took about 2 seconds on my computer, which is dozens of times slower than the first frame. So, this task should not only solve layout problems.

Related

NFR_PREVIEW_PERFORMANCE_R0

How to demo

Start Sophie, insert a text frame with the page size, paste the first half of "Под игото" by Ivan Vazov and try to auto-chain it.This should be about 150 frames of chained text. If it performs considerably fast, save the book and re-open it in a new instance of Sophie.

Design

The current auto-chaining algorithm is ineffective. It adds a page to the book, in another auto action inserts a frame in it, in another one applies the template and chains it to the head frame. If then the text is not laid out completely, repeats the steps. Every action causes updates in che GUI, adding a head text frame to a chain even destroys the old view and creates a tail view, which then recomputes. This can be avoided if the static helper methods are not used - we can create a tail text frame and add it to the chain directly. Furthermore, all the pages can be added at once - for this action we need a helper method in HotLayout which makes a "dry-run" of the layout in order to calculate the count of needed areas. Unfortunately, adding all the frames in one action does not have any effect - every add causes an update. But head frames will not be created, frame kinds will not be changed and all the pages will be added at once. This is much faster.

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}