Did you try keeping some sort of screen updating going all of the time? Current time, a news feed, something like that?
On 4/9/12 9:52 AM, "Jake Churchill" <reyna...@gmail.com> wrote: So, any suggestions on a possible workaround to try? Currently, we have the clients reverted back to AIR 3.1 and it's working fine but they have to constantly deny the update. I'm considering bundling the app w/ AIR 3.1 using that Captive Runtime but I really don't want to do that either. Please let me know if you think of anything. Thanks! -Jake On Mon, Apr 9, 2012 at 11:08 AM, Alex Harui <aha...@adobe.com> wrote: Well, we don’t have confirmation that there is a bug in idle management. But if that was the cause, I don’t think there is a way to keep yourself from becoming “idle”. I’m just recalling the kinds of issues that came up when they started idle management a few years back. Google “Adobe AIR idle” for a review. On 4/9/12 8:08 AM, "Jake Churchill" <reyna...@gmail.com <http://reyna...@gmail.com> > wrote: Alex, Is there a way to keep the app from being "idle" when in the background? When do you anticipate a fix for this? Thanks! -Jake On Thu, Apr 5, 2012 at 6:08 PM, Alex Harui <aha...@adobe.com <http://aha...@adobe.com> > wrote: Sounds like a bug in the idle management in AIR. They’ve been trying different things to reduce CPU usage when “idle”. If you are getting mouse events, check the targets to see if they make sense. A popup overlay would likely change the target. Or just dump the display list on a mouse event and see if it makes sense. On 4/5/12 8:52 AM, "Jake Churchill" <reyna...@gmail.com <http://reyna...@gmail.com> <http://reyna...@gmail.com> > wrote: Alex, It appears there is a bug for this: https://bugbase.adobe.com/index.cfm?event=bug&id=3155398 I set handlers on enterFrame and exitFrame on the chart component as well as a one of it's parents (the main display container) and they fire constantly (several times per second). This continues after the freeze. I also added mouse and keyboard event handlers and they also fire just find when the app is frozen. Everything seems to work fine except for the rendering. I have tried running this in the debugger and profiler and I cannot ever get the app to freeze there. I've let it run overnight and still no freeze. With the production app running in AIR it'll freeze after around 10 minutes pretty consistently. This is why I've been using this Monster Debugger, so I could grab debug traces on the production app without relying on flashbuilder. Regarding the idea that this is popup related... I have popups inside the windows using Alert components, some that use custom components and PopupManager and I have some global popups that open new native windows with information inside. All 3 function just fine and do not cause the app to freeze. The app seems to freeze more if I just let it run in the background. If I play around with it a lot, it'll take a lot longer to freeze. Thanks! -Jake On Wed, Apr 4, 2012 at 10:42 PM, Alex Harui <aha...@adobe.com <http://aha...@adobe.com> <http://aha...@adobe.com> > wrote: Did you check bugbase.adobe.com <http://bugbase.adobe.com> <http://bugbase.adobe.com> <http://bugbase.adobe.com> to see if this is a known issue? If you set enterFrame and exitFrame event handlers, do they get called? If so, how often? How about mouse or keyboard event? Does the profiler continue to work? What does it say is running? On 4/4/12 7:17 PM, "Jake Churchill" <reyna...@gmail.com <http://reyna...@gmail.com> <http://reyna...@gmail.com> <http://reyna...@gmail.com> > wrote: Windows for now. I haven't been able to duplicate issue on a mac but it doesn't mean it's not there. I have not altered the renderMode so it should be running auto. CPU runs between 0 and about 8% depending on how much data is coming down the line (socket connection). Memory spikes as high as 180MB but runs consistent around 25MB in the profiler. In task manager, I usually see around 120MB. If I leave the chart open all day then there's a ton of data and I'll see it up around 180MB. But, that's equal or less than a single tab in firefox so it should be fine. The nativeWindow I'm working with still responds. I can maximize/minimize, but can't resize it. The nativeMenu, however, is dead as well as all content inside the window. As I said, I have a global error handler which traces out stuff in Monster Debugger as well as logs stuff to a file on my desktop and I don't get any info either way. I'm tracing out every data object that I get over the socket as well as every chart update event and the main content area's update event. They continue to respond. It's like everything is there, but there's a block on the app visually. Thanks for your help! -Jake On Wed, Apr 4, 2012 at 7:36 PM, Alex Harui <aha...@adobe.com <http://aha...@adobe.com> <http://aha...@adobe.com> <http://aha...@adobe.com> > wrote: Mac and Win? Different GPU configs? What does memory and CPU for the process look like? On 4/4/12 2:37 PM, "Jake Churchill" <reyna...@gmail.com <http://reyna...@gmail.com> <http://reyna...@gmail.com> <http://reyna...@gmail.com> <http://reyna...@gmail.com> > wrote: Alex, It's intermittent, but routinely happens after the app has been open for 10-15 minutes. But, it's not EVERY time. I've tied in Monster Debugger and I can see after the freeze that updates, data and certain component lifecycle events that I'm looking at are still firing, just no visual. About half the time, I just get a snapshot frozen where the last update happened, and sometimes the screen is completely white. -Jake On Wed, Apr 4, 2012 at 4:12 PM, Alex Harui <aha...@adobe.com <http://aha...@adobe.com> <http://aha...@adobe.com> <http://aha...@adobe.com> <http://aha...@adobe.com> > wrote: Is it intermittent or can you reproduce it at will? On 4/4/12 12:32 PM, "Jake Churchill" <reyna...@gmail.com <http://reyna...@gmail.com> <http://reyna...@gmail.com> <http://reyna...@gmail.com> <http://reyna...@gmail.com> <http://reyna...@gmail.com> > wrote: Coders: I posted an issue regarding the update to AIR 3.2 recently but I now have more information. The app appears to freeze but I've plugged in some debugging tools and network monitors and I have been able to find out that the rendering of the app freezes, but the app itself continues to run. Data continues to fly in, update and render events continue to fire on the components in question. Focus appears to be acknowledged as well. I've messed with a global error handler but I'm not seeing any errors being thrown. The basic app structure is this: Main app opens a login screen, after successful login, the main app hides itself and opens up 1-3 windows, all of which manage their own data/events, etc. I've been debugging events at the main app level as well as windows and I'm getting feedback from both at the appropriate times. I've seen an issue on an ipad app that freezes mid animation and the workaround was to add something else to the display list. I coded in a workaround like that which adds a small transparent image to the display list of components as well as the window's stage and still nothing. I REALLY REALLY need some kind of help here. I've been searching for 3 days without any luck of the problem even being acknowledged other than the one ipad game source. Here's that blog post again: http://www.blog.arnlweb.com/adobe/flash/air-3-2-rendering-freeze-bug/ Please please help me out if you can. Thanks! -Jake Churchill -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
