... .  .    .       .joeberkovitz.com

Too many TextFields and not enough beer makes FP9 crash

I’m working on an interesting and involved project (that I can’t say very much about right now), and it uses a ton of dynamic TextField objects on the screen. I thought things were going superbly, but my app started to crash the player at odd times as the display became more complex. I wanted to tear my hair out, but said hair is kind of short-to-nonexistent and it was hard to get a good enough grip. I tried to reproduce the crash, but each time I thought I knew what was causing it and made the “fix”, it would come back.

It was right around then that I recalled David Coletta of the Buzzword team mentioning at Flex Camp Boston that the Buzzword application uses a bunch of clever techniques to avoid creating and destroying TextFields as the user types (since they use lots of them to render what appears to be a unified display of a rich-text document). Among other things, he mentioned that they pool TextField instances offscreen — while keeping them on the display list — and reuse them by bringing them back onscreen to show stuff as needed.

I commented out the TextField instantiation in my app. Mercifully I had wrapped it inside another object called TextGlyph that isolated the rest of my code from any TextField mechanics, so this was actually very easy to do. The app started working reliably — if you didn’t count the fact that it stopped showing most of the information on the screen.

My next attempt was to rewrite TextGlyph to maintain a cached, shared BitmapData object into which I drew a single master TextField instance. I then used this bitmap to render the text to the screen. The display became functional again, and no more crashes. I felt kind of satisfied, until after a few days I realized that the text didn’t look as good any more. The quality of the anti-aliasing was subtly degraded by drawing the text to a BitmapData, not to the screen. (In fact, I’d had to forego setting the text field to AntiAliasType.ADVANCED because it wouldn’t even draw to the bitmap if I did that.) I tried to convince myself that it still looked fairly okay. You know how those things go. The fact is, it looked bad and I didn’t want to bite the bullet.

Well, the bullet was finally just bitten. My solution was a challenging one to code up, but now I have no more crashes and I am using real TextFields so the display quality is great. The recipe:

• Place a separate, transparent TextFieldDisplay sprite above the whole display. This sprite holds all the TextFields needed by the display. Unused ones are invisible.
• Substitute a new class called TextFieldProxy for TextField. This “pretends” to be the text field to the rest of the app, but actually manages a set of pooled TextFields in the above TextFieldDisplay.
• TextFieldProxy listens to its own ADDED_TO_STAGE and REMOVED_FROM_STAGE events. ADDED_TO_STAGE events cause the proxy to request its associated TextFieldDisplay to either create a new TextField child or to recycle an existing unused one and unhide it. REMOVED_FROM_STAGE events tell the display to put the TextField back on a “free list” and hide it until another proxy needs it.
• The TextFieldProxy has to manage the appearance and contents of the associated TextField, so that it appears in just the right spot with the right text and formatting.
• The TextFieldDisplay forwards its mouse events back to a TextFieldProxy that it finds with getObjectsUnderPoint(), adjusting the events’ mouse coordinates as needed. This is needed because otherwise the TextFields “eat” the mouse events (since they’re on top) and the events never get to the proxies.

There it is. Kind of a weird episode, that I hope no one out there runs into, but if you do… you’re not crazy!