Thanks for explaining that Daniel!!
In the app XML, we have to set renderMode to "direct" in order for AIR (we are targeting Windows) to access the GPU. The Ant script doesn't need anything special in order to ensure this, correct? Does mxmlc use the renderMode parameter from the app XML?
By "modified the code that applies the resize to the native content", what I did was to also apply the resolution and position to the Starling content, so that the 2 contents overlap correctly. For testing, I commented out the part which applies the change to the Starling content, but the issues are still there. Posting them again so we don't need to scroll up, but with some small changes in italics:
When mousing over Flex components, part of the screen flickers. It looks like it's just white rectangles.
Tooltips that end up overlapping the letterbox border at bottom, when I move the mouse away so the tooltip disappears from the Flex/Flash rendering, an image of it remains flickering in the black border at the bottom.
After resizing or changing screen mode (full screen, windowed, maximized window), a duplicate of the previous content (Flash content included), the same size that the content was previous to the resize, flickers within the black surrounding area.
My big question now is, when the Starling content is set up to not occupy the entire "window" space, what is drawn outside of that? Because of issue 3, with the Flash content flickering in there, I'm totally thrown off -- I figured that the GPU was drawing the app background color inside the empty space, but why would the GPU be rendering the Flash content that was previously in the same spot? That's also the space in which the tooltip after-image appears (issue 2). Probably these 2 will be corrected with the same fix.
Did you mean "baseline" profile? You wrote render mode, so I'm not sure. I tried "baseline" profile, and the issues are still there.
The issues do happen on other computers too.