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
Hi Bart, Yes, there are disadvantages as well as advantages to the virtual table. The time must be spent rendering at some point. That means it must be done either before the whole page is displayed (traditional table) or as you scroll (virtual table). The rendering speed is *greatly* influenced by what browser you're using. IE is painfully slow at rendering; in fact, after using firefox with gmail for a while, I recently had the displeasure of having to use IE to access my email. It was a thoroughly awful experience, due solely to the slowness of rendering in IE. Gmail isn't a qooxdoo application, but the same issues apply. Firefox is way, way faster than IE and I understand, but have not had the opportunity to experience for myself, that Webkit-based browsers such as Safari are much faster yet. One area to experiment with would be pre-rendering the next and previous "page" of data in the "background" so that scrolling is merely a matter of making the new rows visible or moving them onscreen or otherwise reversing whatever mechanism was used to hide them after their background rendering. The problem is that this could get in the way of user interaction if not implemented properly, and it might add quite a bit of complexity to the virtual table. If you are using IE, please try your application using either Firefox or a Webkit browser and let me know your results. If you had been using IE, I expect you'll be very pleasantly surprised. (Then you get to take on the unenviable job of convincing the users of your application that they should switch to a reasonable browser...) If you'd like to take a stab at modifying the table widget to pre-render next and previous pages, I'll be glad to review your work for inclusion. It would need to provide enough benefit in "usability" and perceived speed, while still having code that's easy enough to maintain, but that may all be achievable. Let me know! Cheers, Derrell ------------------------------------------------------------------------- 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
