Fri 09 Jul 2010 06:39:17 AM UTC, comment #13:
Fixed in trunk finally.
|
Mon 07 Apr 2008 07:47:15 PM UTC, comment #12:
the container used in string_table and in PropertyList
is a multi-index container.
For string_table the two indexes are:
1: case-sensitive index
2: case-insensitive index
For Propertylist the two indexes are:
1: composite key index (name/namespace)
2: order index (this should thoretically be used to order
enumeration and make array element access easier, but
for sure isn't used currently for both)
|
Mon 07 Apr 2008 09:25:51 AM UTC, comment #11:
hmmm, just googled the hash algorithm. There seemed to be many available functions to hash a random string to a integral. Now the only thing makes me feel uncomfortable is that the string_stable and the container in propertyList are a bit too complex to my taste.
|
Mon 07 Apr 2008 08:50:20 AM UTC, comment #10:
> If we skip the "key" abstraction, rather then do:
> string -> key -> property <------ [1]
> We'd do:
> string -> property <------ [2]
|
Mon 07 Apr 2008 08:48:18 AM UTC, comment #9:
> If we skip the "key" abstraction, rather then do:
> string -> key -> property
> We'd do:
> string -> property
There should be a speed improvement in theory.
For[1], the speed complexity in theory is O(n) + 1 or O(n) + O(log2(m)), where n is the length of the give string and m is the number of the total strings in the property list.
O(n) + 1 if string -> key uses hash and key -> property hashes again.
O(n) + O(log2(m)) if string -> key uses hash and key -> property works with map.
For[2], the speed complexity is O(n)*O(log2(m)) if we use map directly, since we need to search the map for log2(m) times and each time there are n characters to be compared at worst case.
Of course, for[1] the practical effect is doubtable. eg. There should be a very effective hash algorithm with little collision for random given strings, which is really difficult according to my knowledge.
|
Mon 07 Apr 2008 06:52:57 AM UTC, comment #8:
for (1): yes, we can retrive the value, just not the property-cased name. This is an SWF<7 only issue, as SWF7 up are case-sensitive
so every permutation of case would get it's own string_table::key
If we skip the "key" abstraction, rather then do:
string -> key -> property
We'd do:
string -> property
Pretty straightforward isn't it ?
Except the 'key' was added with a purpose that was not
speed improvement, but support for swf9 features for which
we don't have tests (concept of 'slots').
|
Sat 05 Apr 2008 02:10:01 PM UTC, comment #7:
> Only way I can think to fix this owuld be for
> string_table::key to be not just an index, but the index
> associated to the looked-up case-sensitive string followed by
> a list of other ids associated to other strings that match in
> case-insensitive way.
Also over-complex to me.
Some comments and questions fllowed the disscusion on IRC.
For the global string_table, there seems to be two problems:
(1)case sensitiveness. It only occurs when the AS user wants to retrieve the original cases(not the value) of the certain variable, right? The value of that variable can be still accessed correctly.
(2)string to key map(string_table::find). This step is too costing according to the profile.
In the current design, if we want to find a named property, the algorithm is: string--->key--->property we wanted. Now if you dropped the global string_table, how are the steps to get the given value of the named string? I am not sure how the 'map' you mentioned on IRC works for us.
|
Thu 03 Apr 2008 03:43:07 PM UTC, comment #6:
The issue is still open.
We currently only keep the case of the first (globally)
used string.
This means, for instance, that you can't have different
cased strings in different objects (talking about SWF<7
of course, as from 7 up we're case sensitive).
There are tests for this in case.as IIRC.
Culprit is the global string_table, mapping a string
to an index in case-insensitive way.
Only way I can think to fix this owuld be for string_table::key
to be not just an index, but the index associated to the
looked-up case-sensitive string followed by a list of
other ids associated to other strings that match in case-insensitive way.
Sounds pretty much overcomplex to me, but don't even fill like
trashing the whole string_table thing as Chad mentioned
we needed the concept of "slots" for SWF9...
|
Thu 03 Apr 2008 01:50:04 PM UTC, comment #5:
Not sure. I think my own tests have already been fixed. But strk seems have found something new IIRC.
|
Thu 03 Apr 2008 01:35:31 PM UTC, comment #4:
Can we close this?
|
Tue 29 Jan 2008 10:44:40 PM UTC, comment #3:
This should be fixed in Head.
PROPNAME() is now a no-op, we might want to follow
a code review to make sure no useless string copies
are made on the assumption that PROPNAME would return
a copy...
|
Mon 17 Dec 2007 08:26:49 AM UTC, comment #2:
>This is probably a minor problem, but still might brake some
>movies...
I guess this might be a big problem. All variable references should be kept the original cases as when they were defined.
>it seems that Gnash simply converts all members to lower case
If this is true, then it is not only a compatibility problem, but also a performance problem.
eg. I guess the case convertion is only needed when both the following two conditions are true: (1)swfversion<7; (2)the named variable couldn't be found without convertion.
If it's a general case that people don't mix cases when programming in AS, then doing the convertion only when needed would probably speed up the VM(a lot).
I'll follow some tests.
|
Thu 13 Dec 2007 03:14:35 PM UTC, comment #1:
This is generic to all objects, which may still come out uppercase/mixedcase when enumerating them.
Gnash always converts case instead.
|
Thu 13 Dec 2007 02:58:47 PM UTC, original submission:
This is probably a minor problem, but still might brake some movies...
I know that array indexes (correct: object members) are case-insensitive (at least for some SWF versions). However, it seems that Gnash simply converts all members to lower case, while the proprietary player keeps case.
function do_test() {
var foo=[];
foo["BLA"] = 1;
for (var item in foo)
trace(item+" = "+foo[item]);
}
This will print "BLA=1" with Adobe player but "bla=1" with Gnash. Note that (foo["bla"]==foo["BLA"]) but the value of "item" may be used for other purposes inside the "for" section for which case may be important.
|