>Does the text-fix also work if the member is not on the stage, or >not even in a sprite?
No. The sprite needs to be on-stage and visible for the speed-up to occur. -If it only 'fixes' while on the stage, then it might have to do with the sort of 'mini-updatestage' i anticipate is happening when modifying staged text-members. Sounds right to me, but I can't put any other text sprites on the stage, because it's not in the design spec to do that. I wish I could, but I can't. -Does a regular 'updateStage' also introduce a fix? No. It doesn't. That was the first thing we tried. -Have you tried to eliminate conceptual parts of your test, ie: is it the number of objects alone that grinds, or is generically using ancestry, or is it specific to some of your complex code - say DOM-XML? Yes. I have strategically commented out and/or segregated chunks of code to other repeat loops in order to pinpoint where the slow-down is actually occuring, and it is indeed a result of my object creation and complex ancestry tree. I took out the calls to DOM-Lingo, and that definitely wasn't the problem, either. It's really looking more and more like a by-product of my complex architecture. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ Christopher Watson Sr. Software Engineer Interactive Web Media Lightspan, Inc. Tel 858.824.8457 Fax 858.824.8001 ___________________________ [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
