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:b...@xabber.de > http://identi.ca/bwy > > _______________________________________________ > Gnash-dev mailing list > Gnash-dev@gnu.org > 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:b...@xabber.de http://identi.ca/bwy
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
