Community
Participate
Working Groups
It would be more efficient if SEF did not create a StyleRange for text that uses the widget's default foreground color. Doing so leads to a lot of unnecessary StyleRange objects. Also, when the user is allowed to set the foreground, all these style ranges will have to be updated vs. just changing the widget's foreground color. SEF should investigate changing this. Doing so will improve performance of the Java Editor, especially for large files. NOTES:
PRODUCT VERSION: 125
I believe there is major potential here for performance improvements. If the java editor took advantage of the default foreground color and used this for it's "other" style (i.e., what non java tokens are colored), the number of style ranges that are created and set would be significantly reduced. I ran some numbers and it's on the order of 50% less. These are the number of styles created for some CUs. The "not needed" number is the number of styles where the foreground, background, and font style are the same as the widget's values for these (i.e., no need to create a style in this instance). set styles range size 29291 (not needed 10721) set styles range size 2806 (not needed 1094) set styles range size 17698 (not needed 8662) set styles range size 29291 (not needed 10721) Less styles is better. When styles are added/removed the styles array has to be manipulated to accomodate the change. Also, every time a text change occurs, the styles have to be updated to account for the change. And so on. I think this change should be considered.
Probably the easiest way to do this would be to get rid of the "other" concept as a settable thing and instead have it be the editor's default text style and foreground color.
Updating this to include the typing scenario that I found in the Java Editor. During typing setStyleRange is being called each time a character is typed, such that typing a word like "public" will cause 6 redraws to occur as follows: p pu pub publ publi public In this case, it would be more efficient to call setStyleRange just once (i.e., when a word actually does get a style). I'm not sure how hard that would be to do, but one thing that seems easy would be to not call setStyleRange if the style is not different than the defaults for the widget (related to the PR above). That would cut down on the number of redraws. If I continue with the above example and type "void", during each redraw of the characters in void, "public" is also getting redrawn. So void leads to 8 redraws: public v public vo public voi public void And then if I continue and type "test", I get 12 redraws (and so on): public void t public void te public void tes public void test So that's a total of 26 setStyleRange calls (and 26 redraws) that could - in the most optimized case - be handled with 3 setStyleRanges (and 3 redraws).
Resetting priority to P3. Will be reassessed for the next release.
*** Bug 90497 has been marked as a duplicate of this bug. ***
The fix for bug 251224 improved things quite a bit.
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.
