Hi Slava,
> The text member has only about 500 characters, but there's a noticeable
> delay before the color changes after the mouseclick. This happens
> with many
> text members in the same movie.
>
> Has this been noted before? Do these crashes make sense?
>
> If so, is there a workaround?
I posted something similar earlier this month, but got no replies.
FYI, here it goes again (and sorry again for the length):
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.
[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!]
