In Adobe AIR, I recently had to change from using a transparent window to a non-transparent one, and I've never really worked with non-transparent windows without system chrome. Doing so has created a very painful situation due to AIR's redraw bugs on Windows when using non-transparent windows.

Transparency performance on Windows is bad, but it's not Adobe's fault. Windows has bad transparent window performance. However, on Windows, there are major redraw issues with AIR on a non-transparent window, and none of these issues are present in non-AIR applications.

When you minimize a window in AIR, it resizes the application to 160×31, and moves it to -32000, -32000. I can understand the move, but the resize doesn't make sense to me. Especially considering the minSize of the Window is much larger than that.

Because of the resize to 160×31, when you restore the app from a minimized state it resizes the application from that small size back to the size it was before you minimized. On transparent windows it resizes before you can see it, which is why I never saw this before. But, on a non-transparent window, you can actually see your application redraw from 160×31 to the size it was before you minimized. This looks terrible.

What happens whenever you change the window state from Minimized to Normal or from Normal to Maximized, or Maximized to Normal, the move happens first, then, about 100ms later (though getTimer() claims they happen in the same millisecond), the resize happens. This is an clearly visible to the user, and really doesn't look good.

Additionally, on this specific project, when AIR resizes my window to 160×31, it causes all kinds of negative issues with elements that are not meant to draw to that small of a dimension (I set the minSize of the window for a reason). Because of the delay in resizing after the move as outlined above, these issues are visible for a moment when you restore from a minimized state, but sometimes, elements inside an HTMLLoader do not resize correctly unless I resize the application by 1 pixel after restoring.

The best I can do is in the RESIZE listeners check to see if the afterBounds is 160×31 and ignore it if so. So, I do the check for 160×31 in my onResize listener, ignoring the resize if those are the afterBounds values, and that mitigates the issue except for a couple important exceptions.

First, you still see the two step redraw occur, except that since the application isn't resized smaller, it just looks like the application is masked for that split second. The second issue is that I have an HTMLLoader playing a swf with wmode="opaque" inside it and what happens on redraw is that even though the application is "masked" by the smaller window size (since I'm ignoring the resize), the swf in the HTMLLoader is visible beyond the bounds of the NativeWindow 160×31 size until the resize occurs after the move. This isn't the worst thing in the world, but it's not that great either. It's definitely better than the visual consequences of redrawing the application to 160×31.

Another example of this move-wait-resize behavior is when you maximize a non-transparent AIR window. First, it moves the window to -4,-4 (-8,-8 on Windows 7) and then resizes the window to fill the screen. Because of the delay, you see maximize happen in two steps. You see the window jump up to the top left corner first and then you see it resize to fill the screen. This doesn't happen with transparent windows and it doesn't happen with any other application on Windows.

It's really disappointing that something so basic is so buggy. I don't like that AIR resizes the window to 160×31 when you minimize, and I really wish they could move and resize non-transparent windows at the same time since other applications on Windows work that way.

As it is, I'm stuck trying to work around these issues and mitigate them as much as possible. I'm still hoping our commercial application will be a shining example of the kinds of things you can make with AIR, despite AIR's flaws. Most of the bad rap AIR gets is undeserved since most of the time, it is developers not knowing how to manage memory and other such nonsense. But in cases like this, it's something fundamental and specific to how the window draws on the most common target platform, Windows, and is completely out of my control.

All I can do is mitigate the issues as best I can, and write blog posts outlining the problems in the hops that the AIR engineering team will fix these issues in a future release.

Added to Adobe Bugs on Feb 8th