Community
Participate
Working Groups
StyledText has new API that allows to separate the styles from the ranges (see StyleRange). This allows to reduce the memory consumption compared to using just StyleRange-s. In order to support this we will have to introduce new API in Platform Text and change all clients in Platform Text and JDT Text plus inform other clients. Platform Text will have to convert old API calls and merge the result with the usages of the new API calls before calling StyledText API. This includes a major rewrite of TextPresentation. NOTE: StyledText is converting to the new structure when the old APIs are called.
3.2 time permitting.
Has to be shifted to 3.3.
This reaches deep into the APIs and is too late at this point for 3.3.
Created attachment 175181 [details] Extended version of TextPresentation In an earlier project of mine (a PL/I editor) I discovered how important the new StyledText API is. When I tried to process huge source files (nearing 1 megabyte) it brought Eclipse to its knees. But when I used the new StyledText interface directly in the presentation repairer (instead of the normal processing), it was reasonably usable. The performance difference was night and day! One problem, of course, was that text annotations were not merged properly. In a current project, I'm using an extended projection viewer. While I was at it, I decided to extend TextPresentation as well so that it uses the new StyledText API while still allowing in-text annotations to be merged. I am attaching the source for my extended TextPresentation in its current state, and have included some commentary to explain the changes. It adds API, but as far as I can tell none of the old API is broken. It seems to be working, although more debugging is certainly needed. I have no idea if this will be of use to you directly, but feel free. If anyone is working on this problem perhaps it will make interesting reading. At least it demonstrates that the problem can be solved, although production code might not do it the same way I did. Please let me know if I can help further. Would you like this in the form of a patch file? Bill Fenlason
Hi Bill, which version of Eclipse do you use? SWT internally changed their code to reduce the memory so that the new API is not always needed. Could you attach your code together with a test case that shows the memory benefits?
Dani, The preliminary code in the attachment I posted was based on the 3.6 TextPresentation. Do you know which version of StyledText contains the changes you mentioned? I will want to check that out. I didn't notice changes in 3.6, but I haven't looked closely yet. The memory savings are external to the StyledText widget and relate to the ability to share and reuse StyleRange objects. (StyleRange extends TextStyle) Currently when a presentation is generated, StyleRange objects can not be shared and a different (new) StyleRange object is needed for each token in the presentation. For large source files that can be a big number, since typically the average token length is 5 or less. If the StyleRange objects are shared by providing the offset and length separately as int arguments (to the TextPresentation addStyleRange method, etc.), only a small (fixed) number of model StyleRange objects are needed. The StyledText API allows shared StyleRanges but currently the TextPresentation does not. The StyledText API doesn't help much because it isn't used. (Undoubtedly you know all that, but other readers might not be as aware of the situation.) Unfortunately I'm unable to generate a test case to quantify the memory savings and performance difference right now.
>Do you know which version of StyledText contains the changes you mentioned? Since 3.2. As you can see from the implementation, the old methods call the new ones that try to optimize the memory. So far we simply didn't start to add the new APIs to TextPresentation because our use for that class is in the text viewer and hence we only benefit if we also rewrite all the related code. If only adding the new APIs to TextPresentation helps you then we can do that but as previously said, we need a regular patch and test cases for the new APIs.
Yes, corresponding changes to the TextViewer are necessary if the text viewer is to use the more efficient API. My project extends TextViewer. The changes are straight forward but I'm still testing them. I'll append the TextViewer changes in the near future. In the attached version of TextPresentation, the applyTextPresentation() method is modified to demonstrate the use of the new API. The TextViewer changes are similar. Certainly the bulk of the use will be through the TextViewer, but note that other callers, such as the HTMLTextPresenter or 3rd party code can still use the old TextPresentation API. Naturally, it is essential that the old API keep working while the text viewer gets the benefit of the 3.3 StyledText API. When I've finished testing I'll generate patches. It's early to discuss test cases, but I assume the sample XML plugin editor may be a reasonable start.
>but I assume the sample XML plugin editor may be a reasonable start. You can use that to test the initial implementation on your side but I'd expect to see additional tests in org.eclipse.jface.text.tests.TextPresentationTest and also memory usage comparisons e.g. when typing in the Java or Text editor.
Created attachment 175676 [details] Extended version of TextPresentation (Updated) This is an updated version of TextPresentation as an extension. Patch will be provided after more testing.
Created attachment 175677 [details] TextViewer override This is an override for TextViewer which allows it to use the new version of TextPresentation and thus the 3.3 StyledText widget API. A TextViewer patch will be provided after more testing.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
