bugGnash - The GNU Flash player - Bugs: bug #21791, Property name case

 
 

bug #21791: Property name case

Submitted by:  Udo Giacomozzi <udog>
Submitted on:  Thu 13 Dec 2007 02:58:47 PM UTC  
 
Category: ActionScriptSeverity: 4 - Important
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Benjamin Wolsey <bwy>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 09 Jul 2010 06:39:17 AM UTC, comment #13:

Fixed in trunk finally.

Benjamin Wolsey <bwy>
Project MemberIn charge of this item.
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)

Sandro Santilli <strk>
Project Member
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.

Zou Lunkai <zoulunkai>
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]


Zou Lunkai <zoulunkai>
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.

Zou Lunkai <zoulunkai>
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').

Sandro Santilli <strk>
Project Member
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.

Zou Lunkai <zoulunkai>
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...

Sandro Santilli <strk>
Project Member
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.

Zou Lunkai <zoulunkai>
Thu 03 Apr 2008 01:35:31 PM UTC, comment #4:

Can we close this?

Benjamin Wolsey <bwy>
Project MemberIn charge of this item.
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...

Sandro Santilli <strk>
Project Member
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.

Zou Lunkai <zoulunkai>
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.

Sandro Santilli <strk>
Project Member
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.

Udo Giacomozzi <udog>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bwy (Posted a comment)
  • -unavailable- added by zoulunkai (Posted a comment)
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by udog (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 09 Jul 2010 06:39:17 AM UTCbwyStatusConfirmed=>Fixed
      Assigned toNone=>bwy
      Open/ClosedOpen=>Closed
    Thu 03 Apr 2008 03:43:07 PM UTCstrkStatusReady For Test=>Confirmed
    Tue 29 Jan 2008 10:44:40 PM UTCstrkStatusConfirmed=>Ready For Test
    Mon 17 Dec 2007 08:30:05 AM UTCzoulunkaiSeverity3 - Normal=>4 - Important
      StatusNone=>Confirmed
    Thu 13 Dec 2007 03:14:35 PM UTCstrkSummaryArray index case =>Property name case

    Back to the top


    Powered by Savane 3.1-cleanup1