| 34 | | 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. |
| | 34 | 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. Another problem is that the layout is slow. It is created in the HeadTextFrameViews every time a change in the chain occurs. This includes adding a new frame to the chain. The good thing here is that reusing the previously created areas solves this problem. We consider an area layout reusable, if: |
| | 35 | * The area used for the layout is the same (ImmArea has equals()); |
| | 36 | * The area is full, e.g. no more text can be laid out in it; |
| | 37 | * The area does not contain the beginning of the interval, where the text has changed; |
| | 38 | * The text we want to lay out is exactly the same (has the same styled hash) or has the same ID as the laid out one (this means that it derives from it). |
| | 39 | In this case, there is no need of creating a new area layout. The effect is that when a frame is added to the chain, the layout uses all the previously created areas and creates only the new one. |
| | 40 | There is a slowdown in large text when creating layout for them. The main reason is that for every line it creates a LineBreakMeasurer. The measurer needs an AttributedCharacterIterator, and it can be created from an AttributedString. The string needs a StringBuilder, which uses all the characters in the text in order to provide an interator for a single line. This is done for every line until the end of the text, for every area. For a text with more than 100 000 chars, this is very slow. The problem can be solved by re-using the attributed string in every sub-text of a given one. It is the same and does not need to be re-created. The lines are created by using subText(), so a single AttributedString will be made for every change. |
