Changes between Version 8 and Version 9 of TEXT_PERFORMANCE_R0

Timestamp:

05/15/10 12:05:55 (15 years ago)

Author:

kyli

Comment:

--

TEXT_PERFORMANCE_R0

@@ -55 +55 @@
 The processedText() is currently an auto property. It also depends on the current selection options, the raw text and the lastChange() property. When you type a symbol, the caret is set, which sets new options, then the mark is set, which also sets new options, the raw text is changed, and the lastChange() is set. So, the text is processed minimum 4 times and therefore laid out minimum 4 times (it was actually 6 times, but I don't remember why). 
 
-Replace the auto property processedText() with private ImmHotText getProcessed() method.  
+Replace the auto property processedText() with private ImmHotText getProcessed() method. Of course, if it is not automatic, it should be called by another methods. They should be: setCaretInfo(), update(..), and maybe setProcessOptions(..). I say maybe, because setProcessOptions(..) is used for 2 purposes: 
+ * A logic wants to change the way a text is processed (for example, quick search is performed). Then the text must be processed immediately. 
+ * The selectionOptionsSync() property wants to change both selection and caret options. The text could be processed only once, after the second set. 
+So, the best idea I have is to extract the code of setProcessOptions(..) in a setOptionsInternal(..) method, which takes one more argument: ''shouldProcessText''.
+
+Of course, there is a problem with the manual calling of getProcessed(). It is that I dunno (:) who shall call the method when the change comes outside a client logic (this should be the case with file and server accesses). The problem is very similar to the one in TEXT_SERVER_R0 (the selection does not update in file and server accesses), so I propose to resolve them both in the next week.
+
+The processors usage seem to be a bit misunderstood by us during the previous task, maybe because of lack of good documentation (my fault). The problem is that the returned TextEffect by the processor's methods should contain the change, which transforms the last processed text to the new result (maybe a picture should be drawn for the implementation, showing the meaning of the changes I will make there). I found out that a wrong change returned caused the large text to cause assertionError in ImmDosTree (Oh, don't ask why) and eventually the "GC overhead limit exceeded". Just a note, since I am not sure why this happens, I cannot be sure that this is the real reason for the GC error. 
+
+Hm. CaretProcessor, SelectionProcessor and SearchProcessor don't actually need a lot of optimizations - they just apply a style to an interval in the text. I will look again their code, but I doubt that much can be done there. The real problem is with the LinksProcessor, which can be much faster. Maybe the best idea is to use code, similar to the code in CaretProcessor, since it is designed to reuse unaffected intervals in the text. So, nothing special, we get the modified interval, process it again, concatenate it with the rest of the text, and return the result. Bla :)
+
+