Hi Tim, Are these performance hits you talk about related to the waiting time it takes to 'load' a xml or is the time needed to 'parse' a loaded xml file? In my experience flash is already lightning fast for the parsing of xml. I had no problems with it before. Is using xml for UI definition really a performance hit in such a way it prevents users from having a great user experience? Cheers, Ben Smeets
________________________________ From: [EMAIL PROTECTED] on behalf of Tim Walling Sent: Thu 8/18/2005 8:03 PM To: Open Source Flash Mailing List Subject: Re: [osflash] Breaking loose with XPML I've dealt with the same question. I was working on a project that went from "content only" being data driven, to "we want to be able to create more channels in the app and we have to be able to customize everything". You reach a point where you start to see a performance hit because you're generating the entire app UI, parsing XML, drawing and loading assets, etc. I think eventually runtime generation of a UI in Flash should be very possible without encountering issues like this. If the Flash player was built with things like native E4X support, then having the player interpret a descriptive XML document might not be an issue. This is what we're doing everytime we view a webpage right now (browser -> html) and it's usually the goal of most XML like UI markup languages (XUL, XAML, etc). I would love to see if MM down the road addresses this issue and eventually creates a player than interpret and render say MXML, client side/runtime. This probably wouldn't happen though because it takes away from their authoring software sales so I guess we'll be stuck with the solution where we have to write AS code on top of the player that then interprets some UI markup language. Maybe as player performance continues to improve and XML performance in Flash improves this won't be such a bad way to go. Tim > why re-generate the UI > everytime the swf ran ? wouldn't it be too slow or requring too much > cpu resources ? really worth it ? _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
<<winmail.dat>>
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
