Hi Jim.
Do you mean that Firefox3 is 10% or 10X faster? Just curious. For me
Firefox 3 is comparable in speed to Firefox 2. Nothing to beat Webkit
for now.
Sebastian
Am 04.08.2007 um 20:38 schrieb Jim Hunter:
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
-------------------------------------------------------------------------
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
