I haven't yet found an easy guide to building firefox in visualstudio, else i might profile it to see what would need work to speedup qooxdoo.
-----Original Message----- From: Sebastian Werner [mailto:[EMAIL PROTECTED] Sent: Sun 5-8-2007 0:06 To: qooxdoo Development Subject: Re: [qooxdoo-devel] qx.ui.table.Table with (too) many columns 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
<<winmail.dat>>
------------------------------------------------------------------------- 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
