I was able to come up with a simple test case, and I've attached it to http://jira.openlaszlo.org/jira/browse/LPP-8697
I hope this helps! -chris On Mon, Jan 11, 2010 at 11:18 AM, Chris Kohlhardt <[email protected]> wrote: > I'll give it another shot today and see if I can come up with a test case. > > -chris > > > On Sat, Jan 9, 2010 at 5:23 PM, Max Carlson <[email protected]> wrote: > >> If there's any way you can provide us with a testcase, that would help >> enormously. I'd be happy to take a copy of the app, in confidence of course >> - I promise to nuke it as soon as I can derive a testcase! >> >> I'm hoping LZOs will be fully working in swf9/10 soon - then you could >> send us a binary library... Thanks! >> >> >> Regards, >> Max Carlson >> OpenLaszlo.org >> >> On 1/8/10 5:15 PM, Chris Kohlhardt wrote: >> >>> http://jira.openlaszlo.org/jira/browse/LPP-8697 >>> >>> On Fri, Jan 8, 2010 at 4:59 PM, Max Carlson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Chris, >>> >>> Any chance you could file a bug at http://jira.openlaszlo.org/ and >>> attach the screenshots/testcase there? If there's a regression in >>> swf9, we really want to take care of it! >>> >>> Regards, >>> Max Carlson >>> OpenLaszlo.org >>> >>> >>> On 1/8/10 4:19 PM, Chris Kohlhardt wrote: >>> >>> The following message bounced when I tried to send screenshots >>> of the >>> problem. >>> >>> On Fri, Jan 8, 2010 at 4:17 PM, Chris Kohlhardt >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> I compiled our using the nightly LPS build, and this results >>> in our >>> application looking very jumbled. SWF9 and SWF10 both show >>> the same >>> issue. >>> >>> If I turn the debugger on, the application looks correct. >>> (screenshots attached) >>> >>> It sort of looks like constraints aren't working as >>> expected.... >>> but I don't have any evidence besides visual evidence to >>> prove this. >>> >>> I spent some time trying to isolate the issue, but haven't >>> had any >>> luck so far. Our application is pretty complicated, so >>> it's pretty >>> tough to isolate issues. >>> >>> Any ideas? >>> >>> -chris >>> >>> >>> On Fri, Jan 8, 2010 at 3:43 PM, Henry Minsky >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> wrote: >>> >>> Did you mean the issue is that your code (which you've >>> been >>> running in swf9) compiled for swf10 has some artifacts, >>> or that >>> compiling to swf9 in the nightly build has problems? >>> >>> >>> >>> On Fri, Jan 8, 2010 at 5:34 PM, Chris Kohlhardt >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> I just gave the nightly build a quick spin, and >>> immediately >>> ran into rendering issues which I assume are related >>> to >>> SWF9.... Is SWF9 support going away? >>> >>> We have decided not to adopt SWF10 yet because we have >>> customers who are in the 'Enterprise' and the data >>> we have >>> suggests Flash 10 adoption is still far less than >>> 90% there. >>> I think the Adobe numbers are misleading >>> >>> ( >>> http://www.adobe.com/products/player_census/flashplayer/enterprise_penetration.html >>> ) >>> and the analytics on our web site suggest Flash 10 >>> has maybe >>> 80% penetration. >>> >>> -chris >>> >>> On Fri, Jan 8, 2010 at 11:04 AM, Henry Minsky >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> wrote: >>> >>> We just made some changes to significantly >>> reduce the >>> RAM required for SWF9/10 compiles. You can try >>> them out in >>> a nightly build, and tell us if you see any >>> improvement >>> (or any new bugs, god forbid) >>> >>> regarding the 'incremental compile' option, If you >>> compile from the command line, the incremental >>> option >>> will be useless right now, since the >>> cache it stores is in RAM. If run on the server, >>> I don't >>> know if it makes any difference either, it's >>> really >>> just a placeholder feature now and does not have >>> an >>> efficient implementation, it requires more work >>> to be >>> optimized to make much difference. >>> >>> >>> >>> On Fri, Nov 20, 2009 at 4:39 PM, Chris Kohlhardt >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> After a good amount of work, we've managed >>> to get >>> our application completely migrated to >>> OL4.6.1 and >>> SWF9. >>> >>> Thank you very much to everyone involved in >>> making >>> the SWF9 runtime a reality. The performance >>> of >>> Gliffy is so much faster now, it's almost >>> unbelievable. We're entering QA next week, >>> and we >>> expect to release SWF9 Gliffy in mid December. >>> >>> One thing we noticed is that compilation of >>> SWF9 is >>> a lot slower. After some digging, we were >>> able to >>> speed things up by: >>> - setting compiler.swf9.incremental=true in >>> lps.properties >>> - allocating at least 2GB of memory to the >>> tomcat >>> instance running the lps >>> - moving developers to a pure 64bit OS >>> (Clint moved >>> to Windows 7 after a long stint with XP) >>> >>> Are there any other performance tips to >>> consider? >>> >>> thx! >>> >>> -chris >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] >>> >>> <mailto:[email protected]>> >>> >>> >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >>> >>> >>> >>> >>> >
