Hi John, then have a look at the table stuff in the incubator project. That contains sortable, pageable, scrollable table solutions which can have bulk renderers. It's also worth seeing the gwt mosaic project. It's table solutions are based on the tables of the incubator project (and seems to be easy to use but it is still under development).
Best regards, Tibor On Dec 29, 9:58 pm, John Lonergan <john.loner...@gmail.com> wrote: > 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
