Did you also see that you can make the Flash 9/10 not quite as bad by setting the canvas frame rate lower?
It is interesting how the slight differences in the runtime environments is sometimes an advantage. Often if I can't solve a bug in one runtime, looking at it in another will make it more obvious (e.g., swf8 has better warnings for finding type-ohs of attribute names, dhtml has the fallback to the browser debugger, and swf9/10 have the fallback to the fdb debugger). On 2010-03-14, at 10:16, Rami Ojares wrote: > Yes, I was able to confirm that when my node count increases it does not have > bad performance effect in dhtml runtime. > So it seems like I am suffering from the flash bug you refer to. > Unfortunately things look different on that platform and some other features > that work ok in swf10 do not work efficiently on dhtml. > (One of them is resizing a lot of objects, one is initializing(creating) > objects, one of them is drawview working differently etc.) > > I am still figuring out if I could make it work with swf8 but it gives me > some errors in initializing the app. > > I think I will build a TreeNode pool for my system so that only the amount of > visible nodes would be in the displaylist. > And then hope and pray for the bug fix. > I voted for it and am watching it now. > > Actually this is a good reason to keep your app compatible with all the 3 > runtime environments. > When one of the runtimes has a show stopper you could always use the other > one for the time being. > And if it would not be so hard I would have done it already ;-) > > Thanks Tucker for pointing this out for me. > > - Rami > >> http://jira.openlaszlo.org/jira/browse/LPP-8072 >> >> And this is the relate Adobe bug: >> >> http://bugs.adobe.com/jira/browse/FP-1149 >> >> If that is the root of the bug, there is not much you (or OpenLaszlo) can do >> except reduce the number of objects in the display list. > > >
