thx for the info jens, do you say there is no way to keep the browser responsive but to do less work/ transfer less data on/to client? is there at least a way to keep browser responsive if browser has to do much work/logic?
if i understood it right: transfer much data is worse than to do much work on client side? so all efforts should go into reducing data amounts transfered to client? but lets assume for a moment that the rpc-call isn't the problem but the logic that handles the data received. could this cause a freeze of the browser? if yes how to avoid it? probably by using schedulInterupted? how to use it? or how to optimize the view in the way you suggested? At the moment the view shows the filtered tree and keeps an unfiltered tree to provide the tree faster if user clears the filter/resets the tree. the tree rendeing and realtime filtering is very fast - i think no incremental command is necessary. the only problem is the first loading/rendering of the tree - the tree is submitted in an very special data structure (arrayList, composite pattern) that makes live filter as fast as it is. i could try to create this structure on client side (more logic less data)... -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/-VJJx2Br-REJ. 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.
