Sorry for the length of this post. SUMMARY: setting member.word[n].color OR word[n].foreColor is MUCH slower on Win 9x variants than Win 2K. BACKGROUND: I've been working on a (windows-only) application. In one section of this, the user is required to click on words in a text member. This text member contains around 125 words. I have been changing the color of the word clicked to provide instant visual feedback that they did indeed click that particular word. PROBLEM: dynamically changing the color to an rgb color, or the foreColor using a paletteIndex color, is fine on my development machine - Windows 2000 Professional SP2. When I run the same movie on Win 98 SE2 or Win ME, changing the word color takes a massive time hit after a few words are quickly clicked. Running the text with "copy" ink or directToStage or "saveBitmap" or whatever variation I've tried makes no difference. RESEARCH: I've trolled the direct-l archives, updateStage's quirk-list and MM's technote section and found nothing relating to this. There are a couple of threads from direct-l relating to an apparent limit on setting the color of words past ~word[240]. DUPLICATION: create an empty movie, loop it on a frame, create a text member and put a bunch of words into it - 20 or so should demonstrate the problem. Drop the following behavior onto the text sprite: -- <TEXT COLORIZATION BUG TEST BEHAVIOR> property pSprite property pMember on beginSprite me pSprite = sprite(me.spriteNum) pMember = pSprite.member end on mouseDown me sMillis = the milliseconds cLoc = the clickLoc tWord = pSprite.pointToWord( cLoc ) -- the offending line of code: pMember.word[tWord].color = rgb(255, 0, 0) elapsed = the milliseconds - sMillis put "#mouseDown: elapsed =" && elapsed end on endSprite me pMember.color = rgb(0,0,0) end -- </TEXT BUG TEST BEHAVIOR> Run the movie, click on each word *as quickly as possible* and check your message window for timing results. Comment out 'the offending line of code' and click again. RESULTS: on my machine (Win 2k Pro sp2) I get: -- "#mouseDown: elapsed = 19" -- "#mouseDown: elapsed = 10" -- "#mouseDown: elapsed = 12" -- "#mouseDown: elapsed = 15" -- "#mouseDown: elapsed = 18" -- "#mouseDown: elapsed = 21" -- "#mouseDown: elapsed = 24" -- "#mouseDown: elapsed = 27" -- "#mouseDown: elapsed = 30" -- "#mouseDown: elapsed = 34" -- "#mouseDown: elapsed = 37" -- "#mouseDown: elapsed = 40" -- "#mouseDown: elapsed = 42" -- "#mouseDown: elapsed = 46" -- "#mouseDown: elapsed = 49" -- "#mouseDown: elapsed = 53" -- "#mouseDown: elapsed = 55" -- "#mouseDown: elapsed = 59" -- "#mouseDown: elapsed = 62" -- "#mouseDown: elapsed = 64" on a machine with Win 98 SE I get: -- "#mouseDown: elapsed = 29" -- "#mouseDown: elapsed = 59" -- "#mouseDown: elapsed = 67" -- "#mouseDown: elapsed = 106" -- "#mouseDown: elapsed = 108" -- "#mouseDown: elapsed = 157" -- "#mouseDown: elapsed = 180" -- "#mouseDown: elapsed = 173" -- "#mouseDown: elapsed = 196" -- "#mouseDown: elapsed = 216" -- "#mouseDown: elapsed = 215" -- "#mouseDown: elapsed = 243" -- "#mouseDown: elapsed = 267" -- "#mouseDown: elapsed = 283" -- "#mouseDown: elapsed = 325" -- "#mouseDown: elapsed = 364" -- "#mouseDown: elapsed = 409" -- "#mouseDown: elapsed = 400" -- "#mouseDown: elapsed = 390" -- "#mouseDown: elapsed = 430" They both appear to slow as a general trend, but for Win 98 alarmingly so! This holds for Win ME also. I realize that cpu speed and RAM probably have an impact also, but having tried 2x Win 2K and 3x Win 98/1x Win ME systems it holds true that the Win 9x variants slow to a crawl while the Win 2K systems are (acceptably) fast enough not to notice a lag while clicking/changing color. I have tried this with D8 and D8.5 and there is no perceivable difference - ie. the trend holds. I have tested on a machine that dual-boots to Win ME and Win 2K and it behaves as described; so it's not (only) RAM, CPU and video card differences. Totally untested on any Mac systems, or Win 95. REQUEST: Would anyone care to confirm this? Feel free to mail me directly, or return results to the list. It would be especially useful if someone could try Win NT as I no longer have access to a machine running Winnt. I'm wondering if this speed difference behaves on Winnt as a Win 9x variant, or as on Win 2K. Most interesting would be if it behaved like Win 2K, as this would suggest it was related to how the OS handles text rendering. WORKAROUND: for D8 and above: use imaging lingo and copyPixels() (to the stage) a highlight over the word clicked. D7.02: use a series of off-stage shape sprites with add/lighten/(insert approprite inkType) and move these into position by calculating the rect using charPosToLoc from the text member. Anyone have any insights/suggestions? Should this be considered a bug (and logged with MM), or is it a FOL? Thanks, -Sean. [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/LUJ/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!]
