Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313291 - [Table] slow relayouting when the visible area is large
Summary: [Table] slow relayouting when the visible area is large
Status: RESOLVED DUPLICATE of bug 338196
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 330370 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-18 03:56 EDT by Thomas Haskes CLA
Modified: 2012-03-29 05:48 EDT (History)
2 users (show)

See Also:

Attachments
sample project showing the problem (6.10 KB, application/octet-stream)
2010-05-18 03:59 EDT, Thomas Haskes CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Haskes CLA 2010-05-18 03:56:51 EDT 
Open and launch the attached sample project "testtable". It consists of a section and a table below the section.
Resize the rap window to a small size. Open and close the section (to force the table to relayout itself).
Now resize the window to a big size (or maximize it). Open and close the section (to force the table to relayout itself) again. Notice that opening and closing the section now is slower than before (small window size).
I noticed that the problem does not depend on how much data the table contains, but on the size of the visible area of the table, which means that a big visible part of the table leads to slow relayouting.
Comment 1 Thomas Haskes CLA 2010-05-18 03:59:27 EDT 
Created attachment 168867 [details]
sample project showing the problem
Comment 2 Ralf Sternberg CLA 2010-05-24 06:19:49 EDT 
I tested your example with different browsers. First of all, a full page table with 32 columns and > 35 visible rows results in a lot of DOM elements to re-layout which is a challenge for older browsers. With a modern browser like Chrome, there is almost no noticeable delay. But with FF 3.0 or IE 7, the delay is really annoying.

Here are two possible optimizations:

* More than half of the time is used up by the DOM operations in TableItem.js#_renderText. I guess there is still room for improvement, e.g. sorting out which element properties really need to be changed.

* I noticed that cell divs are rendered even for empty cells. I remember that in the original design those divs are only needed if there is an image, text or cell background color set.
Comment 3 Ralf Sternberg CLA 2010-11-16 11:48:43 EST 
*** Bug 330370 has been marked as a duplicate of this bug. ***
Comment 4 Ivan Furnadjiev CLA 2011-08-02 09:14:47 EDT 
By resolving the Bug 332524 the client-side widgets of Tree and Table are now merged. Tim, is this still an issue with the new implementation?
Comment 5 Ivan Furnadjiev CLA 2012-03-29 03:43:16 EDT 
Tim, can we close this bug?
Comment 6 Tim Buschtoens CLA 2012-03-29 04:45:52 EDT 
I can#t say if the reporter is okay with the current state, but we DO have Bug 338196 to track Tree/Table performance issues.
Comment 7 Ivan Furnadjiev CLA 2012-03-29 05:14:48 EDT 
(In reply to comment #6)
> I can#t say if the reporter is okay with the current state, but we DO have Bug
> 338196 to track Tree/Table performance issues.
OK. This bug report is completely outdated as we have a new client-side Table implementation (see bug 332524). I will close it as WONTFIX. Further optimizations will be tracked by bug 338196. Thomas, please reopen it if you disagree.
Comment 8 Ivan Furnadjiev CLA 2012-03-29 05:22:01 EDT 
I decided to change the resolution state to duplicate of bug 338196.

*** This bug has been marked as a duplicate of bug 338196 ***
Comment 9 Thomas Haskes CLA 2012-03-29 05:48:19 EDT 
I agree, no need to reopen from my point of view.