Hi lummie, You're right to avoid putting 10,000 DOM nodes into the page, but even loading that much data behind the scenes will put quite a load on the browser (especially IE!!). Is it possible to load the data incrementally as the user scrolls (think of Google Maps as a useful analogy - it loads extra images in anticipation of your scrolling, and sometimes there's a noticeable lag, but mostly it works smoothly).
The freeze-up that you're seeing could be down to any one of three things: 1. loading the XML document 2. running the XPath query 3. rendering a subset of the data on screen (unlikely, as the suibset is small) I'd recommend you reduce the problem to a simple test page, in which you can perform 1, 1+2 or 1-3. Then set up some sort of timer to record how long each step takes, and have a look in Task Manager at the footprint of the browser in MBytes. Then you will know where the problem lies, I would hope. My gut feeling is that loading the XML doc is enough to bring IE to its knees, but a decent set of numbers and measurements are much better than the gut feelings of me or anyone else :-) HTH Dave On Friday 13 April 2007 09:59, lummie wrote: > I am loading such a large amount of data due to application > requirement. The applciation has to be able to display a hierarchy of > 10s of thousands of items. Traditional trees approaches (e.g. an > asp.net rendering for example) are not quick enough, you expand an > item that has 30,000 children and they try and add them all to hte > HTML dom. The tree I am currently prototyping, loads the hierarchy as > an XML document and then only renders a viewport of it to the html > document. Effectively, no matter what the size of the hierarchy on > about 20 nodes are written to the dom. As the user scrolls the > virtual viewport, I jsut replace the 20 nodes as the viewport moves. > > It is performant, from the point of view of retieving the xml document > from the server, loading into the XMLdom, and scrlling the viewport > but the intial selection of nodes via an xpath statement, takes time > (an acceptable time) but seems to lock the browsers thread so my > progress indicators don't update. > > Hence, the question, If I can launch the XPpath query on a seperate > thread and raise an event back to the tree when it is complete, it > will hopefully stop the dom rendering thread being blocked. > > Hope that clarifies things. > > On 13 Apr, 09:43, Christophe Porteneuve <[EMAIL PROTECTED]> wrote: > > Hey there, > > > > lummie a écrit : > > > Baring in ming that I am relatively new to javascript and I am a c# > > > programmer, I was wondering if it is possible to process the xpath > > > query in a separate thread. Is it possible to create threads in > > > javascript ? Are there any extensions to prototype that can help. > > > > AFAIK, script execution in any particular viewport is single-threaded. > > > > That being said, I must say I question the relevance of your 100,000+ > > node loading strategy on the client side. Massive data processing is > > server side business, at least in the current state of the technology. > > > > -- > > Christophe Porteneuve aka TDD > > [EMAIL PROTECTED] > > > > > -- > This email has been verified as Virus free > Virus Protection and more available at http://www.plus.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
