Bugzilla – Full Text Bug Listing
| Summary: | TextSizeDetermination causes high CPU usage and flickering | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | ANS <ans.mail> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | ivan |
| Version: | unspecified | ||
| Target Milestone: | 3.2 M2 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://git.eclipse.org/r/#/c/80809/ | ||
| Whiteboard: | |||
Fixed in master with change https://git.eclipse.org/r/#/c/80809/. Now it's possible to override the default text size storage max size of 10 000 by specifying the custom value with system property "org.eclipse.rap.rwt.textSizeStoreSize". |
Opening views with lots a content causes high CPU usage, wait cursor and flickering. Lots of data means: each view has a table with a least 1000 rows and sometimes more than 20 columns and additional tooltips. Having 6 or more of that views open causes the described phenomena. They are all different and to not have similar textual content. A look in the thread dump at that times shows permanent calls of TextSizeStorage#handleOverflow. The default storage size is definitly to low. I'have hacked this value because an official way is not provided: org.eclipse.rap.rwt.internal.application.ApplicationContextImpl context = (ApplicationContextImpl) RWT.getApplicationContext(); TextSizeStorage tss = context.getTextSizeStorage(); Method setter = TextSizeStorage.class.getDeclaredMethod("setMaximumStoreSize", int.class); setter.setAccessible(true); setter.invoke(tss, 100000); Invoking the code above from another session immediately solves the problem. There is no reason to stay with the default value for years. I strongly recomment to work on this. Saving little memory at this place can be a show stopper for deciders who are not realy trusting the whole RAP technology, even it is getting better and better :-)