Hi Norm, I have built a similar app, composed by a data-provider engine (with a small web server embedded) and a normal browser (IE, Moz family) hosting Adobe viewer.
This app also exchanges loads of data every 1-2 seconds by using the same machanism of fragment parsing and replacing. What I've noticed is that the VM (eaten by the browser) starts (let's say) at 30M and it begins to rise slowly and smoothly until (let's say) 40M...after that it seems that the garbage fires up its work and the VM drops instantly to 30M... The cycle loops as described, but in the average there is not any leak. What I may tell you is: - I have tried with IE6, Mozilla and FireFox, they hosting ASV 3.01; - I don't remember if I've tried also with ASV 6 (I cut this version because isn't reliable at the moment); - Platform is Win2000 (server); - The script hosted in the SVG doc is running by the ASV own's engine; I don't think that ASV6 would have a memory leak, the engine should be the same as the 3. You must check carefully the correct dropping of useless object (in general). I had in the past some trouble with DOM manipulation, because I didn't understand well the XML technology. Cheers Mario On Friday 10 December 2004 18:53, nj_petterson wrote: > Hello all, > > I am developing an application using SVG for long-running dynamic data > displays, and am using Adobe's SVG Viewer 6 "getURL" from within a > repeated "setInterval" ECMAscript function to smoothly replace a > server-generated SVG fragment (i.e., repeatedly doing removeChild and > appendChild). For my client application I am using ASV6 as an ActiveX > control directly from a wxPython program, rather than via its usual > usage as a browser plugin. > > Unfortunately, after several hours, my application consumes all the > virtual memory available on my machine. > > Instead of running my client program, if I use Firefox 1.0 to view the > same page, repeatedly replacing the same (even unchanging) fragment, > the same eventual consumption of all virtual memory also occurs. > However, using InternetExplorer in exactly the same way, virtual > memory usage, while gradually increasing, is periodically reduced and > does not appear to leak. Over a few hours, my client program and > Firefox both grow to over 100MB VM while IE settles around 30MB. > > I have verified that I am using the Adobe SVG internal script engine > (by displaying navigator.appName on page loading). > > Before noting the IE behavior, I suspected that my scripted DOM > manipulations were somehow prohibiting garbage collection of the SVG > fragments I was replacing (and googling showed others with potential > circular reference memory leak issues). However, IE appears to be able > to manage my SVG viewer's memory usage effectively enough. > > Does anybody know how IE deals with ASV6, so that I can do the same in > my own application? Thanks in advance for any clues. > > Regards, > > Norm Petterson > > > > > > ----- > To unsubscribe send a message to: > [EMAIL PROTECTED] -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit my > membership" ---- > > > > > Yahoo! Groups Sponsor > > > > ADVERTISEMENT > > > > > > > > Yahoo! Groups Links > > To visit your group on the web, go to: > http://groups.yahoo.com/group/svg-developers/ > � > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > � > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ------------------------ Yahoo! Groups Sponsor --------------------~--> $4.98 domain names from Yahoo!. Register anything. http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/1U_rlB/TM --------------------------------------------------------------------~-> ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
