Re: [Gnash-dev] Property case and AVM2

[Benjamin Wolsey]

My development branch is available here for anyone interested in the
changes:

bzr branch lp:~bwy/+junk/gnash-devel

or web interface: https://code.launchpad.net/~bwy/+junk/gnash-devel

Be aware that there are still compiler warnings and various ugly things
in it! It takes no account of AVM2, and the as3compile tests fail
because I removed a function that was faking static properties.

bwy

Am Samstag, den 03.07.2010, 11:17 +0200 schrieb Benjamin Wolsey:
> Hi list,
> 
> Gnash has a problem with case insensitive properties in SWF6 and below.
> I've been working on a fix for this, which corrects most of the
> behaviour.
> 
> The original implementation relied on a case-insensitive string table.
> This worked fine for case-insensitive comparison and lookup, but ruined
> property names. An example:
> 
> During startup, common strings are added to the table. One such string
> is "onLoad". In SWF6, creating a new object with a property ONLOAD will
> then work, but the name of the property will always be onLoad, not
> ONLOAD.
> 
> I wasn't keen on dropping the string table, so I created a map of all
> case-sensitive strings to a caseless string. It's then possible to
> compare string_table::keys either with or without case-sensitivity.
> 
> This has a time cost when adding strings and a memory cost because all
> non-lower-case strings have to be added to the string table in a
> lower-case version, and the two keys have to be mapped to each other. My
> tests showed no big speed difference, and there's only one string table
> so the memory costs are acceptable (I also removed some unnecessary
> cruft from the previous string table).
> 
> The second stage is to change lookup in the PropertyList. I started by
> using a simple list instead of the boost multi-index container. The
> disadvantage is that there is no lexicographical ordering, so all
> lookups have to iterate through the list until the required key is
> found. This was acceptable in most cases, but for objects with many
> properties (mostly arrays) the performance hit was huge.
> 
> There are two obvious remedies here:
> 
> 1. Use a special array typing to index array properties.
> 2. Use multi-index again.
> 
> I didn't get a satisfactory result from 1, but in principle it should
> work. The disadvantage is that it won't help for non-array objects with
> large numbers of properties. I haven't noticed that the pp displays this
> behaviour.
> 
> Choice 2 increases the memory requirements for all objects, but provides
> very quick lookup for all properties, regardless of their type. This
> approach increased the speed for versions 7+ to previous levels.
> 
> However, the problem of case-insensitive lookup remains. The difficulty
> here is that a string_table reference is required to find caseless
> string_table::keys for comparison. There's no possibility of using this
> to index a multi-index container without storing a caseless key for all
> properties.
> 
> I've currently hacked this so that the performance is acceptable under
> most conditions (the iterating lookup is only done if a case-sensitive
> one fails and the property name is not lower-case), but a better
> solution is needed.
> 
> So question 1 is: does anyone have other suggestions or preferences
> based on what I've described?
> 
> Then there is the second point: removing AVM2 code.
> 
> The current AVM2 implementation adds various data members and member
> functions to PropertyList, Property, as_object etc. None of this
> behaviour is correct, yet it makes AVM1 refactoring and optimization
> much harder. 
> 
> The AVM2 implementation was started with the fundamentally incorrect
> assumption that it could be mixed with AVM1. This results in all sorts
> of things (e.g. static properties, classes, super objects) appearing to
> work in some cases, when in fact they don't have a snowball's chance in
> hell of ever doing things right.
> 
> This extends to all the AS3 stubs, which similarly rely on AVM1-style
> properties. Again, this will never work and serves no useful purpose.
> 
> Because the whole caboodle adds about 10 minutes onto compilation time
> (on a fast machine!), adds useless data all over the place, increases
> startup time and memory footprint, increases executable size, slows
> everything down, makes optimization and improvements to AVM1 difficult,
> and blocks a real implementation of AVM2. I propose to drop all the
> stubs, to remove all AVM2 code from as_object and the properties, not to
> add AVM2 by default, and not to expect any passes in the AVM2 tests. The
> AVM2 code in libcore/abc would stay, as it's not completely wrong.
> 
> Anyone else for this?
> 
> --
> Free Flash, use Gnash
> http://www.gnu.org/software/gnash/
> 
> Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
> C++ and Open-Source Flash blog - http://www.benjaminwolsey.de/bwysblog
> 
> xmpp:address@hidden
> http://identi.ca/bwy
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

--
The current release of Gnash is 0.8.7
http://www.gnu.org/software/gnash/

Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
C++ and Open-Source Flash blog - http://www.benjaminwolsey.de/bwysblog

xmpp:address@hidden
http://identi.ca/bwy

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil