Hi - I've taken a look at the grids in the incubator and they are definitely much faster (200ms in IE7).
But those grids are very basic. I need a grid that's a bit more functional .. - sorting - scrolling - fixed non-scrolling header row (i.e.header doesn't scroll with rest of grid) Are such features available in a fast grid and are there any examples? Thanks John On Dec 29, 1:18 pm, gregor <greg.power...@googlemail.com> wrote: > Hi John, > > 1) I concur with your timings on that incubator scroll table demo for > FF at 3s, but not on IE at 15s: mine does it in 5s. Suggest something > strange about your IE set up?? > > 2) The DHTMLX example lazily loads rows on demand using what looks > like a scroll listener. Overall table size probably calculated from > secondary DB query for num rows and overall height of scroll panel set > accordingly. So user gets an impression of the overall size of table > and can use scroll bar and/or page ip/down & up/down arrows to > navigate it. It only ever fills in the visible portion. Impressive > trickery, but IMO the only advantage this has over the more > traditional <-prev : next-> button navigation format is user can > scroll right down table quickly using the scroll bar handle. But how > could user know which records they might hit by doing this? Clever > programming maybe but is it good UI design? IMO that is questionable. > There are other ways to make sense of large data sets in the UI. > > 3) Although it takes 3s for FF and 5s for IE to render the incubator > scroll table example for 100 rows, my little test does this in both > browsers <0.5s for 200 records, about 0.5s for 500, and about 3s for > 2000 in FF, slightly longer for the 2000 in IE. OK, mine is running > local and the examples are running over the net, but that doesn't > account for all of the massive difference. This should be telling you > something: tabular data grids can be complicated things, and people > have wide variations in requirements for them, so ready made > generalized grid components need shed loads of code to make them > configurable for everybody's needs. In most cases if you roll your own > component from base GWT widgets you will get blisteringperformance > for your own use cases by comparison because you can build it to do > exactly what you need it to do, and only what you need it to do. > > 4) If I wanted to use a ready made component for this I would head > straight for the new PagingScrollTable in the incubator. Reason being > that nothing makes into official GWT code unless it works as fast as > is reasonably possible. GWT makes no compromise on this. What does a > user care most about: a) how quickly and easily they can get at the > information they need, or b) how pretty it looks in the screen? > > 5) If you are using an Ext family grid widget it will definitely run > slow because there is heaps of Ext framework javascript running as > well as actual widget code. Ext looks great, but does not compete with > base GWT forperformanceor reconfigurability. > > 6) Paging *is* the answer to this problem: As you can see from your > DHTMLX example above, what they do is paging but in a hidden way, i.e. > they try to give the impression that the whole 50,000 rows are loaded, > but of course in reality they are not, and this is obvious when you > play with it because it simply isn't fast enough to deceive the eye. > > regards > gregor > > On Dec 29, 9:30 am, fin <tibor.fi...@freemail.hu> wrote: > > > Hi John, > > > have a look at the bulk renderer feature of the GWT incubator > > project:http://code.google.com/p/google-web-toolkit-incubator/wiki/BulkTableR... > > andhttp://code.google.com/docreader/#p=google-web-toolkit-incubator&s=go... > > > Best regards, > > Tibor > > > On Dec 29, 5:32 am, John Lonergan <john.loner...@gmail.com> wrote: > > > > Hi - yep there was a problem in my test program but now that that's > > > ironed out I'm getting ok'ishperformancein FF3 and Chrome however in > > > IE the perf is poor. > > > > All the time is spent populating the grid / rendering. > > > > IE is the target deployment platform - they only have IE installed. > > > > Have been looking for online samples that are useful for demonstrating > > > a sort of problem I'm seeing. > > > > I found this useful demo that allowed me to verify that what I'm > > > seeing re rendering times is not just a result of my dodgy program. > > > >http://google-web-toolkit-incubator.googlecode.com/svn/trunk/demo/Scr... > > > > I tested by clicking "Add 100 rows" on the Data Manipulation tab. > > > > The relative timings are ... > > > IE 15 secs > > > FF3 3 secs > > > Chrome 1 sec > > > > This is consistent with what I see for my grid test. > > > I'm using com.extjs.gxt.ui.client.widget.grid.Grid > > > > I suspect that the more basic a grid I use, the quicker the rendering > > > will be. > > > > However, I assume one can achieve something similar to the 'big data > > > set example" from > > > DHTMLXhttp://www.dhtmlx.com/docs/products/dhtmlxGrid/samples/loading_big_da... > > > Where we fetch the data in chunks on-demand. > > > > However, I've noticed that the time taken to insert new rows on the > > > GWT grids I've played with takes longer the more rows are inserted. > > > > Are there any good examples of what can be done with big grids without > > > paging? > > > > On Dec 22, 2:15 pm, gregor <greg.power...@googlemail.com> wrote: > > > > > Hi John, > > > > > Yes, compile/browse ought to give you goodperformance. A 200 Person[] > > > > returned over RPC should enable you to resize and show all of them in > > > > a Grid within about 0.5s in web mode (it works in compile/browse too). > > > > Example code below. If it isn't doing so, then something is wrong with > > > > what you are doing I think, not the RPC layer. > > > > > regards > > > > gregor > > > > > public class SandBox implements EntryPoint { > > > > > private VerticalPanel layout = new VerticalPanel(); > > > > private ScrollPanel scroller = new ScrollPanel(); > > > > private Grid grid = new Grid(1, 5); > > > > > private Button fireBtn = new Button("Fire", new ClickListener() { > > > > > public void onClick(Widget sender) { > > > > GenericListServiceAsync proxy = > > > > GenericListService.App.getInstance(); > > > > proxy.getPeople(new AsyncCallback() { > > > > > public void onFailure(Throwable caught) { > > > > Window.alert("RPC call failed"); > > > > } > > > > > public void onSuccess(Object result) { > > > > Person[] people = (Person[]) result; > > > > loadGrid(people); > > > > } > > > > }); > > > > } > > > > }); > > > > > public void onModuleLoad() { > > > > > scroller.setHeight("" + (Window.getClientHeight() - 100)); > > > > scroller.setWidth("100%"); > > > > scroller.add(grid); > > > > > grid.setBorderWidth(4); > > > > grid.setWidth("100%"); > > > > > layout.add(fireBtn); > > > > layout.add(scroller); > > > > layout.setSize("100%","100%"); > > > > RootPanel.get().add(layout); > > > > } > > > > > private void loadGrid(Person[] people) { > > > > > grid.resize(people.length,5); > > > > for (int i = 0; i < people.length; i++) { > > > > Person p = people[i]; > > > > grid.setWidget(i,0,new Label(p.getPersonId())); > > > > grid.setWidget(i,1,new Label(p.getFirstName())); > > > > grid.setWidget(i,2,new Label(p.getLastName())); > > > > grid.setWidget(i,3,new Label(p.getEmail())); > > > > grid.setWidget(i,4,new Label(p.getPhone())); > > > > } > > > > } > > > > > } > > > > > On Dec 22, 11:57 am, John Lonergan <john.loner...@gmail.com> wrote: > > > > > > Thanks Gregor > > > > > > I've hit the Compile/Browse button - I understood that caused the app > > > > > to run in 'web mode' (as opposed to hosted). > > > > > > Or do I need to run it in a standalone tomcat to get a perf boost? > > > > > > John > > > > > > On Dec 19, 1:48 pm, gregor <greg.power...@googlemail.com> wrote: > > > > > > > Hi John, > > > > > > > It sounds like you might be testing this in hosted mode. If so, be > > > > > > aware that hosted modeperformance, especially where RPC is > > > > > > concerned, > > > > > > bears no relationship whatever to deployedperformance. If so, deploy > > > > > > your example and I think you will be amazed at the difference. Note > > > > > > building grids, trees etc involves drawing an order of magnitude > > > > > > more > > > > > > HTML boxes than there are items to display. 200 odd Persons should > > > > > > display < 0.5s when deployed, but go up to 1000+ and you will > > > > > > probably > > > > > > start to notice the browser groaning under the pressure. Then you > > > > > > can > > > > > > either fetch in batches over RPC or (in the say 500-2000 item range) > > > > > > cache all the items on the client and page the grid from that. It > > > > > > obviously varies by situation, but RPC data transfer is one thing > > > > > > and > > > > > > the HTML box drawing is another. > > > > > > > regards > > > > > > gregor > > > > > > > On Dec 19, 2:08 am, John Lonergan <john.loner...@gmail.com> wrote: > > > > > > > > I have been evaluating GWT but have come up against a problem I > > > > > > > cannot > > > > > > > solve/understand. > > > > > > > > I have a little service method that returns a list of 'person > > > > > > > data' > > > > > > > > I am finding that whilst the server side take around zero > > > > > > > milli-secs > > > > > > > to handle the query (100-200 rows) the client is taking seconds > > > > > > > before > > > > > > > the AsyncCallback.onSuccess() callback fires. > > > > > > > > I am guessing that GWT is taking an age to deserialise the > > > > > > > response. > > > > > > > > I cannot afford to wait 2 or 3 seconds to deserialise and then > > > > > > > render > > > > > > > the response. > > > > > > > > I am unsure what factors might be influencing theperformance. Or > > > > > > > tuning/settings I might look at. > > > > > > > > I imagine that populating a long grid (well a couple of hundred > > > > > > > rows) > > > > > > > is something that must be fairly common and that I am doing > > > > > > > something > > > > > > > wrong, or missing a trick. > > > > > > > > Small sets of 10 rows come back fast > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
