It is 300ms per scroll action, regardless if it is 1 row or a pagedown, so if you are using a cursor to step down thorugh a table it is near unworkable. I agree that the bottleneck seems to be in te browser not javascript. well it should be near instantaneous, 600 cells isn't really that much data at all. Horizontal scrolling in the grid is completely smooth, while vertical scrolling isn't, while must users scroll vertically. That kind of behaviour is causing me to get bad feedback from others. is it possible to use native scrolling for say 50 lines, and doing a new page after that ? ie maybe 100 rows in the html table, with native scrolling through that until that is used up and a new html table is made with 100 rows. I believe i allready use a remote table model, any ways the bottle neck is the innerhtml/dom manipulation. the table data is a join from several dozen tables, atleast in the database it is normalized :) The problem is that it is basicly a port of the current desktop application, so i can't change the way the application should work in major ways. the feedback i'm getting from higher up is that i need to show more rows and columns, and that it needs to be faster to be acceptable as a product. I might be able to get a small bit of sponsoring if someone could implement native scrolling for the vertical scrollbar for blocks of maybe 100 rows.
________________________________ Van: Jim Hunter [mailto:[EMAIL PROTECTED] Verzonden: za 4-8-2007 9:57 Aan: qooxdoo Development Onderwerp: Re: [qooxdoo-devel] qx.ui.table.Table with (too) many columns 300 ms to do a page down (20 columns x 30 rows = 600 cells, is a full page not a row scroll) is not that slow. Are you thinking that displaying that much data should be instantaneous? That's not going to happen with any of the toolkits. I have evaluated them all and this is one of the fastest grids out there. I would suggest that you take a look at the remote table modal as it might fit your needs a little better. Plus, reduce the number of columns! If they 'have to see all that data' then I suggest creating views of related data (it sounds like you are doing this since you are now only showing 20 columns) and putting the views in separate grids. Also, if all your data is in a table that has 120 columns, I would seriously suggest doing some normalization on your tables as 120 columns is extremely high for a normalized table. Also, if you reduce the number of rows showinf on the screen at one time I bet you will get more speed out of the scrolling. Jim www.D4PHP.org <http://www.d4php.org/> www.D4PHP-Hosting.com <http://www.d4php-hosting.com/> On 8/2/07, Bart van der Werf <[EMAIL PROTECTED]> wrote: only short strings all data is formatted on the serverside the base data has about 120 columns, but we're bringing it down to 10-20 ish, but this still makes qx sluggish about 20000 rows, but we're using blocks so only about 200 rows are actually on the browser at anytime. on my screen i visually see about 30 rows, and 7 columns. this means that for every single row scroll it rerenders about 600 cells for a 20column table.which takes about 300ms ________________________________ From: Jim Hunter [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 6:27 PM To: qooxdoo Development Subject: Re: [qooxdoo-devel] qx.ui.table.Table with (too) many columns long amounts of code does not equate to more time. CSS Style Sheets are slower to process then inline code is. You never did let us know what your idea of a large grid is. How many rows? How many columns? What sort of data is in the grid, numbers, short strings, very long strings? Images? There could be many reasons you are seeing a slow down, we need to get to the root of the problem. Jim www.D4PHP.org <http://www.d4php.org/> www.D4PHP-Hosting.com <http://www.d4php-hosting.com/> On 8/1/07, Bart van der Werf <[EMAIL PROTECTED]> wrote: I've been looking at what qx generates. the following was the element for a single gridcell """ <div style="position:absolute;left:100px;top:0px;width:100px;height:15px;overflow:hidden;white-space:nowrap;border-right:1px solid #eeeeee;border-bottom:1px solid #eeeeee;padding-left:2px;padding-right:2px;cursor:default;-moz-user-select:none;">5</div> """ Does it really need to be this big? Would it be faster if i would creates css styles with a shortname and use those for the common cases instead of this long sequence for every cell ? greets, Bart ________________________________ From: Bart van der Werf [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 10:10 AM To: qooxdoo Development Subject: [qooxdoo-devel] qx.ui.table.Table with (too) many columns I'm having some performance issues, We are using a very large grid and the number of columns is causing qx to become very slow. At the top of the profiling results of venkman profiler are: 72000ms qx.ui.table.cellrenderer.Default updateDataCellElement : function(cellInfo, cellElement) 22000ms qx.ui.table.pane.Pane _updateContent_orig : function(completeUpdate, onlyRow, onlySelectionOrFocusChanged) No other function comes above 5000 ms. Is it possible to have the same block like behaviour for columns as allready is supported for rows ? greets, Bart ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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
<<winmail.dat>>
------------------------------------------------------------------------- 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
