We are having similair problems.
 
The biggest problem is the complete redraw on minor changes, especially
vertical scrolling, horizontal scrollign works just fine.
 
I'm currently looking into making vertical scrolling work the same as
horizontal scrolling, using very large empty rows to keep the scroll
height down, needing much fewer complete redraws.
 
alternatively i might implement horizontal scrolling the same way as
vertical scrolling, only putting as much columns in the div structure as
are visible.


________________________________

        From: Carsten Harnisch [mailto:[EMAIL PROTECTED] 
        Sent: Thursday, August 02, 2007 9:43 AM
        To: [email protected]
        Subject: [qooxdoo-devel] Performance for Table
        
        

        Using Qooxdoo 0.7 we are encountering performance problems on
large tables with a higher number of cols.

         

        The table-widget is undesirable slow using it with a larger
number of cols. Operating on a table with ~ 30 rows using a page-size of
50 results into a huge DIV-structure with a few thousand div that the
browser needs to render. This results to "endless" rendering loops on
the browser-side (e.g. about 30 secs. with FireFox running on a
dual-core maschine, IE is even worse as aspected) ! The performance
might be acceptable when just using a few cols (~5) anyway completely
missing our requirements.

         

        Digging a bit inside qx.ui.table.pane.Pane (which seems to
responsible of the main rendering loop) and investigating the code here
throws up a few questions:

         

        1)      What is the preferable model here regarding to the
USE_TABLE, USE_ARRAY_JOIN switches. 

        I would assume that using a huge div-tree does not really
produce a fast rendering. Anyway switching to USE_TABLE will recreate
the whole table-data structure on every single interaction.  Even worse
that the internal _updateContent() - method is fired a couple of times.

         

        2)      Is this behavior subject to be changed ? Are there any
improvements on the roadmap? 

         

        3)      Besides the performance issues there are a few weird
issues that needs be changed on the functional side to make the
table-widget really useful in a "real-world"-scenario we are indenting
to use it for (e.g. embedding widgets in table-cells, having a more
understable model regarding the event handling, ...) . Anyway we are
willing to contribute here a few modules ...

         

        Best wishes

        Mit herzlichem Gruss

         

        Carsten Harnisch

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to