Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.0.RC2
-
Fix Version/s: 3.0
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces 3.0 RC1A Build 9/ICEfaces 3 trunk
-
Assignee Priority:P1
-
Affects:Compatibility/Configuration
Description
To reproduce in WPOC:
- Load first tab with Screen 1 content.
- Click on the retrieve button
- Sort on a column. In IE it takes around 25 seconds for the sorted data to be displayed. Any sorts at the time will take around the same amount of time.
- Add a new tab to the tab set via the "+" button.
- Go back to Screen 1 tab.
- Try sorting on any column, sorting now takes around 3 seconds for results to be displayed.
Most of my testing was done in IE8 with IE7 document mode.
- Load first tab with Screen 1 content.
- Click on the retrieve button
- Sort on a column. In IE it takes around 25 seconds for the sorted data to be displayed. Any sorts at the time will take around the same amount of time.
- Add a new tab to the tab set via the "+" button.
- Go back to Screen 1 tab.
- Try sorting on any column, sorting now takes around 3 seconds for results to be displayed.
Most of my testing was done in IE8 with IE7 document mode.
When the ace:dataTable is first sorted, every cell value changes, and the dom differencing will update them each individually, which is a little slow in most browsers, but quite slow in IE. Due to the caching, when changing tabs back and forth, there is no server side representation of the tab's contents any more, and with nothing to dom difference against, the full table is updated, which is a single update and is much faster.
The solution seems to involve detecting these kinds of updates and forcing a full dataTable update instead of numerous piecemeal cell updates.
1. This could be accomplished in the dom differencing algorithm itself, so that if a large table drastically changes, that would be treated differently than the large table slightly changing or a small table drastically changing. Once a sufficiently large number of updates have been found within a region of the dom, matching some heuristic which might even be tunable based on the browser, then the difference could stop comparing, and just ascend to a higher level and make a single replace update. This is the most automatic and fine grained solution. ICE-6600.
2. Modify the ACE DataTableRenderer to detect that a sort or filter has occurred, and then force a full table update. This limits the behaviour to the ace:dataTable, so we don't get the benefit with compat or stock dataTables, and won't give the benefit when the app simply updates its contents. But it's the quickest and easiest solution. We can render a hidden div right inside the dataTable's top level div, that has no id and contains a counter value that increments on each sort or filter, which should preclude the table contents from even being differenced at all, and just update the whole thing. It's ham fisted, but will get the job done.
3. We can accomplish #2 without the hidden div and counter if we had ICE-6601.