Good luck. I have found it hard to fight others that think web
applications should have the exact same speed as native desktop
apps. They currently are slower, and there is nothing you can do
about that. There are limitations in what JavaScript in a browser
can do and how fast it can be done. FireFox 3 promises about a 10X
increase in JavaScript speed but that is still some time off.
If you are using a remote modal and you are seeing delays making a
single row scroll then there is something that you are doing
wrong. You should only see a delay when you are fetching data. And
if you don't have enough rows in your buffer to handle a single
row scroll then you need to re-work your code. I don't use the
remote modal but load many hundreds of rows and I can scroll up
and down without delays. So if you have the data available it
should scroll well. You have to remember also, that there is no
rendering going on with a horizontal scroll, that data is already
created. All you are doing is moving the clipping widow. With
vertical scrolls, the row objects need to be created and added to
the object matrix, so there will ALWAYS be a slight difference
between horizontal and vertical scrolling.
Good luck.
On 8/4/07, Bart van der Werf < [EMAIL PROTECTED]> wrote:
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
---------------------------------------------------------------------
----
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
