Changes between Version 4 and Version 5 of NFR_TEXT_PERFORMANCE_R0

Timestamp:

11/09/09 10:34:15 (15 years ago)

Author:

kyli

Comment:

--

NFR_TEXT_PERFORMANCE_R0

@@ -39 +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.
 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. 
+Another issue is the method HotAreaLayout.splitAreaToLineTexts(). When creating an area layout, the whole text left is given. This method breaks all the text into lines and performs some operations on some of them. It would be better to generate the lines one by one and stop when the area is full. For this purpose, a LineIterator can be created, which will have only one method: nextLine(). It returns the text until the next line break and remembers its new position.
+
 
 = Implementation =