And have a reason more to hate Internet Explorer? ;D Jim Hunter wrote: > Damn! I was hoping they would get the Tamarin version out sooner. Oh well > > Jim > > > On 8/5/07, *Sebastian Werner* < [EMAIL PROTECTED] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>> <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> < >>> http://www.d4php.org/> >>> www.D4PHP-Hosting.com <http://www.D4PHP-Hosting.com> >>> <http://www.d4php-hosting.com/> >>> >>> >>> >>> On 8/2/07, Bart van der Werf < [EMAIL PROTECTED] >>> <mailto:[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] <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> < >>> http://www.d4php.org/> >>> www.D4PHP-Hosting.com >>> <http://www.D4PHP-Hosting.com> < >>> http://www.d4php-hosting.com/> >>> >>> >>> >>> On 8/1/07, Bart van der Werf >>> <[EMAIL PROTECTED] <mailto:[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] <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] >>> <mailto:[email protected]> >>> >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> <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] >>> <mailto:[email protected]> >>> >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> <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] >>> <mailto:[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] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> <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] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> <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/_______________________________________________ >> <http://get.splunk.com/_______________________________________________> >> qooxdoo-devel mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> <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] > <mailto:[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
