Prev: Flash components and Lingo variables
Next: something 's wrong with the linked files
From: Darrel Hoffman on 24 Apr 2008 17:21
Okay, I've got a text object, 16 lines with various tabs in it for columns.
I've discovered that accessing this text member in order to change things is
abyssmally slow. E.g.:

member("Text Object").line[2].word[4] = "Blah"

takes about 1 second to execute, which is terrible, because with 16 lines
times 11 columns, it takes about 3 minutes to populate the text once. If I
do the whole line at once:

member("Text Object").line[2] = TAB & "a" & TAB & "b" & TAB & "c" & TAB &
"Blah" etc...

it executes in about half the time, but still way too slow. The only way I
can get this to a semi-decent speed is to change the ENTIRE text all at
once, e.g.:

member("Text Object").text = TAB & "a" & TAB & "b" & TAB & "c" & TAB & "d" &
RETURN & TAB & "a" & TAB & "b" & TAB & "c" & TAB & "Blah" etc...

As expected, the line of code, after a few dozen \ marks, takes up about 2
pages in the script window, because I had to ditch the repeat-loop that was
populating the text before. This is ridiculous - it can't be THAT hard to
change text. Why is this taking so long? I'm seriously considering
replacing this thing with 176 individual text objects, which seems insane,
but it would probably perform better. Is there any less-drastic way of
making this run at an acceptable speed?


From: Sean Wilson on 24 Apr 2008 17:50
Which version of Director are you using, on which platform?

When you say "text object", do you mean #text member, #field member,
#flashComponent, or something else?
From: Darrel Hoffman on 24 Apr 2008 18:23
> Which version of Director are you using, on which platform?

MX2004, WindowsXP

> When you say "text object", do you mean #text member, #field member,
> #flashComponent, or something else?

#text. No anti-aliasing or other fanciness, boring old Arial font. I tried
with #field, but the lack of tabs and adjustable line-spacing made them
basically useless in this case. I've also tried separating it into either
11 separate columns or 16 separate rows. Rows performed better than
columns, but still not great.

Single text object, .line[].word[]: 36-40 ticks per draw
Single text object, .line[]: 24-30 ticks per draw
Single text object, .text: 8-10 ticks per draw
11 Separate columns, .line[] = 13-16 ticks per draw
16 Separate rows, .word[]: 4-5 ticks per draw (This is what I'm settling
with right now)
No text changes at all: 0-1 ticks per draw

So I know it's still the text that's slowing this thing down. I haven't yet
tried it with 176 separate text objects for every single field (I'd have to
make a bunch more room on the score just to be able to fit that, and it'd be
really tedious to set up.

I suppose another option might be to fill a single text object with all 500+
lines at the beginning, and then just use the ScrollTop to do the scrolling
instead of scripting the text changes based on the scroll bar. Of course,
you'd still end up with a long wait the first time it populated (even
longer, since we're talking about 500+ lines instead of just the 16 that
show), but maybe if it were hidden behind a load-screen - still not ideal.
And the single-text object only performed at an even remotely acceptable
speed when I set the entire text in one shot - which took a monstrous amount
of code, and that was just 16 lines. Multiply that to the full 500+ and any
speed advantage is quickly lost. Seriously, there's got to be a better way
to do this...

As for #flashComponents, I'm not touching that. Every time I've used any of
the #flashComponent objects, it's always a pain - first you have to learn a
whole new scripting language to interact with them, second, they take over
your input control (even a flash button object for some reason interrupts
all keyboard input just by being on the screen), and third they have redraw
problems up the wazoo. (Half the time when I go to a new frame where the
flash object doesn't exist, it leaves pieces of itself on the screen for
some inexplicable reason.) As far as I'm concerned, flashComponents are a
broken feature which I will never use again unless there's some major
changes to how they work.


From: Sean Wilson on 24 Apr 2008 18:33
I wasn't suggesting you go near #flashComponents - particularly if
you're looking for performance. I just wanted clarification about "text
object" before progressing.

Where is the text you're using coming from? It sounds like you're
populating a #text member with the results of a database query. The
reason I ask is to try to find a way to optimise alterations. Updating
it, or creating it, at run-time seems to be a requirement, which
suggests something dynamic going on.

Can you provide a cut-down version somewhere for download that focuses
solely on text and performance?
From: Darrel Hoffman on 24 Apr 2008 23:53
> Where is the text you're using coming from? It sounds like you're
> populating a #text member with the results of a database query. The reason
> I ask is to try to find a way to optimise alterations. Updating it, or
> creating it, at run-time seems to be a requirement, which suggests
> something dynamic going on.
>
> Can you provide a cut-down version somewhere for download that focuses
> solely on text and performance?

Not easily. At any rate, it is *sort of* a database query, but not really.
I'm creating the database in Director as a property list, and it's already
created before any of the text stuff happens. I'm sure that it's not the
database query part of the equation that's causing the slow down, however,
as I've placed my tick-counters in such a way that it's only surrounding the
text-changing parts of the code. Much-simplified pseudo-code example:

database =
[[#name:"Alex",#date:"1/2/04"],[#name:"Bob",#date:"3/2/05"],etc....]
--(All of this is generated before-hand, long before any of the code in
question takes place.)
pos = sprite("Slider").pos
--(changes based on the position of the slider sprite)
repeat with i = 1 to 16
record = database[i + pos]
n = the ticks
member("Text Member").line[i].word[1] = record.name
member("Text Member").line[i].word[2] = record.date
etc...
put the ticks - n
end repeat

Since it isn't starting its tick-counter until after the database query, the
number that it puts out should show how long the text-management part is
taking. If I put those lines around the "record = database[i + X]" line, I
get 0's and 1's, so that part is happening lightning-quick. It's very
definitely the text-management that's making it take so long. I was
thinking it was all the complicated tabs in the text field that were causing
the issue (8 columns are center-justified, 1 is left-justified, and 2 are
right-justified), but given that my separate-rows code, complete with tabs
on each row, worked much faster than the separate-columns code (no tabs,
just the entire text member justified), I doubt that's the issue. As for
altering the text at runtime, there will be options to filter the data based
on the values, so, yes, the database that displays would have to be
generated on the fly if you used the filters. But that part of it is not
even implemented yet. (And the creation of the database right now happens
almost instantly, even though I'm generating 500+ entries with a dozen
properties each.) The slowdown is undeniably from the text populating.


 |  Next  |  Last
Pages: 1 2
Prev: Flash components and Lingo variables
Next: something 's wrong with the linked files