12-16-2010 07:59 PM
I was just porting an app developed in AIR to the PlayBook and was amazed at how little I needed to do to get it running (generally speaking, nothing).
Unfortunately, I have a Move with a set duration that has twice the speed on the PlayBook Simulator than it did when I was just running it in the Flash Player.
I sussed out that it was likely the omission of the SWF Flex Metadata from my project, resulting in an unbounded framerate so, thus, an inexplicable and variable speedup. So I put the following in:
[SWF(width="1024", height="600", backgroundColor="#cccccc", frameRate="30")]
...to no avail.
The major complicating factor appears to be that I wrote in MXML, so it was unclear where to put the metadata declaration (in AS3, you just put it before the declaration of the main class' constructor). I found the fx:Metadata tag, but putting it there had as much effect (re: none) as putting it inside the fxcript block where I put my ActionScript.
Solved! Go to Solution.
12-16-2010 08:20 PM
Also, I should mention that the problem also affects timers. I have a second animation based on a flash.utils.Timer that triggers every second. It triggers much more frequently than that on the simulator.
For what it's worth, I'm running SDK 0.9.1
12-16-2010 09:25 PM
Flex usually defaults to a frameRate of 24. You can also set it at runtime by get a reference to the stage, and then setting stage.frameRate = 1. Not sure why you are seeing double the speed, it will vary but not sure by twice as much. What is your Simulator's CPU set to, 1 CPU or more?
12-17-2010 09:32 AM
1 CPU only. 1024MB of RAM, 8GB of disk.
And by looking more closely at the once-per-second manual animation I've got running, the speed appears to be closer to 3x-4x faster...
I've ascertained by reading http://help.adobe.com/en_US/flex/using/WS2db454920
12-17-2010 05:11 PM - edited 12-17-2010 05:18 PM
I reached in to a function and tweaked the value of stage's frameRate to be 1 while it was debugging on the simulator, and it had no effect (though the animation, instead of smooth, was rendered jerky).
I double-checked my calculations for the Move's duration, and it is being calculated out to needing 40s to get from top to bottom.
For some reason, seconds just seem to be coming a lot faster on the simulator. I put in a watch expression for 'new Date()', and, sure enough, the runtime's convinced that time is moving just that quickly. (seconds between breakpoints, minutes between values read). Even the simulator's clock in the top bar of the home screen is moving at an extremely-accelerated pace.
I'm truly at a loss
12-17-2010 09:13 PM
Further developments: I tried reinstalling the simulator from the image, and its clock exhibits the same ultra-quick behaviour as the other install.
12-20-2010 02:01 PM - edited 12-20-2010 03:02 PM
Stop the presses, I've found the solution!
It turns out that this is a VMWare problem, not a tablet OS problem. But, in the interests of completionism, I shall type out the solution here.
The 'guest OS clock too fast' issue is a known one in VMWare circles ( http://kb.vmware.com/selfservice/microsites/search
Apparently, the guest OS's RTC (Realtime Clock) is set using some low-level API that queries the host OS's CPU frequency. There are lots of APIs in Windows that correct for power-saving mechanisms, but the one that VMWare uses does not. So, it reads the power-saving low MHz, and then when VMWare powers on, the CPU kicks it into high gear (and so does the RTC). ...or something like that.
Sorry to take up everyone's forum time on a VMWare issue.