thank you for all replies. i have a few questions:
1) JSON data graph with Javascript Overlay -- i can't find example on this... can someone tell me what is this? 2) so the rendering of the data is probably the reason why an application looks slow..... if the data i want to transfer from server to client is huge..... should i still be using RPC? or is there a better method? currently, i am using gwt-rpc to transfer 2d array of string..... 3 can someone explain to me why the need of JSON and XMl serialisation? besides the need to communicate with non-java server? thanks...... On Apr 16, 6:04 pm, Jason Essington <jason.essing...@gmail.com> wrote: > Their reasoning was that object instantiation was orders of magnitude > slower than simply building the HTML. in some cases even building HTML > on the client was too slow, so they would shuttle it off to the > server. The application would decide at runtime which way was faster, > and use the fastest method. > > For a quick rendering test, you can try to create a 100x100 table > (grid) using GWT widgets, and then do the same thing using > setInnerHTML() (with a string that ultimately has the same DOM) ... > you'll find that while the setInnerHTML() is nearly instantaneous, the > creation of the widgets takes some time. > > Creation of individual DOM elements in javascript seems to be pretty > slow (it is a bit faster in the new generation browsers ff3, Safari4 > and chrome) but setInnerHTML() doesn't create those elements in > javascript, it is done natively in the browser and thus is much faster. > > Another technique that I use when populating multiple "cells" that > have the same HTML structure is to embed a hidden "template" in the > host page. This template has all of the HTML structure, but no > content. I have GWT find and store the elements that will be bound > with data (traverse the DOM of the template only once) from my model > objects, then when I need to fill the cells, I setInnerText, or > setInnerHTML() on each of the found elements from the template, and > once the databinding is complete, perform a getInnerHTML() on the > template, and use that string to setInnerHTML() on the "cell" ... this > works great as there is really no DOM object creation happening in > Javascript, and is considerably faster than building up the widgets > individually. > > -jason > > On Apr 16, 2009, at 9:44 AM, Vitali Lovich wrote: > > > Can you point out the relevant segments within the presentation? I > > skimmed through some parts, & it seemed like they went for just > > building the raw HTML on the client side (hence the reason they > > transfer HTML from the server). > > > Also, they're presentation is for 1.4, so they're reasons might not > > be relevant any more (especially since 1.5 included a lot of > > improvements & 1.6 introduced improvements with the event subsystem). > > > Also, they don't seem to be using deferred binding for some reason > > to get around > > > On Thu, Apr 16, 2009 at 11:19 AM, Jason Essington <jason.essing...@gmail.com > > > wrote: > > You might want to tell the Lombardi Blueprint guys that ... as it > > turns out, they discovered in the development of their application > > that you are mistaken on all points. > > > Feel free to watch their presentation from Google I/O last year if > > you'd like to check my references: > >http://sites.google.com/site/io/using-gwt-to-build-a-high-performance... > > > -jason > > > On Apr 16, 2009, at 9:10 AM, Vitali Lovich wrote: > > >> I dunno about that one two fronts: > > >> 1) All the same DOM elements still have to be created. This would > >> only help if you have such a slow JS engine in your browser that > >> running the DOM manipulations in Javascript is so slow that it > >> outweighs the cost of actually performing the manipulations (which > >> I believe would always be done in native code anyways) > > >> 2) You're transmitting more data across the pipe - the extra > >> markup is unnecessary data & can bloat your transfer by quite a > >> bit, slowing down your responsiveness. > > >> 3) It's not scalable. Your moving rendering code from the client > >> to the server which places more load on the server. Performing > >> string concatenations also isn't cheap (unless you build your own > >> string class that offers fast concatenation through pointers to > >> strings & perform all the stream output yourself). Obviously if > >> the number of users is limited you don't care. > > >> So all 3 reasons together (mainly 1 & 2 though), I don't see how > >> that would help. Obviously some hard numbers are needed as all > >> this is just hand waving guesses of expected behaviour. > > >> On Thu, Apr 16, 2009 at 10:55 AM, Arthur Kalmenson <arthur.k...@gmail.com > >> > wrote: > > >> Just asked a GWT wizard on IRC and turns out I was incorrect. He > >> offered an interesting alternative solution. Build the table as HTML > >> and send that down instead. > > >> -- > >> Arthur Kalmenson > > >> On Thu, Apr 16, 2009 at 10:46 AM, Ian Bambury > >> <ianbamb...@gmail.com> wrote: > >> > 2009/4/16 Vitali Lovich <vlov...@gmail.com> > > >> >> You seem to be saying that: > > >> >> tree t = new tree() > >> >> t.addItem("abc"); > >> >> t.addItem("def"); > >> >> RootPanel.get().add(t); > > >> >> will have fewer reflows than > > >> >> tree t = new tree() > >> >> RootPanel.get().add(t) > >> >> t.addItem("abc") > >> >> t.addItem("def") > > >> >> According to you (at least from what you've said so far) is that > >> the 1st > >> >> snippet will cause 1 DOM reflow whereas the below snippet will > >> cause 2, > >> >> which isn't actually the case AFAIK. Both will only cause 1 & > >> will be > >> >> equally fast. > > >> > I think you are both right, depending on the browser you are in. > >> > FF2 (IIRC) will rerender during a sequence where most other > >> browsers won't. > >> > I don't know when it decides to do that, but most other browsers > >> would be > >> > still displaying your splash screen while FF2 has hidden it and > >> has stuff > >> > dancing about on the screen. > >> > OTOH, if you widget is not attached and you are setting > >> percentage heights > >> > and widths, for example, they will fail. > >> > Ian > > >> >http://examples.roughian.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
