Damn! I was hoping they would get the Tamarin version out sooner. Oh well

Jim


On 8/5/07, Sebastian Werner <[EMAIL PROTECTED]> wrote:
>
> Ok, that's the reason: Tamarin is Firefox 4 - not Firefox 3 :)
> Firefox 3 will be out by the end of this year.
>
> Sebastian
>
>
>
> Am 05.08.2007 um 02:21 schrieb Jim Hunter:
>
> Brendon Eich of Mozilla, claimed many times at TAE that FireFox 3 will
> have the Tamarin engine in it (it's possible that the current alpha does not
> have it in yet) and it will have about a 10X increase in speed. It is a JIT
> compiler for JavaScript developed by Adobe. I have also read other articles
> on Tamarin, some claiming as much as 100X increase in speed.
>
> Jim
>
>
> On 8/4/07, Sebastian Werner <[EMAIL PROTECTED]> wrote:
> >
> >  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
> >
> >
> -------------------------------------------------------------------------
> 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

Reply via email to