I don't know of any way to get called back for rendering data. The player
is a deferred display list renderer.
It only re-renders dirty display objects so in theory you could carve your
screen up into tiles and save some that way.
Are you sure you don't just want to find a fixed-width font that will look
just like the glyphs? Then you should get faster rendering as well.
The font subsystem does not allow for background colors on individual glyphs, also, it seems silly that a TTF rasterizer would be faster than something as simple as a 1bit glyph rasterizer. Also, we use a LOT of switching of character colors and background (>2000 per screen sometimes), having that many HTML tags would surely eat at the memory and slow down crucial manipulation functions. We'd also have to map the UTF glyphs to the 256 IBM/OEM glyphs and that table-conversion process would ALSO be another bottleneck, and we are striving for top speed here. I hope that makes it obvious as to why the TTF rasterizer is overkill and likely too slow and too bulky for our needs.
In my experience this process is called 'invalidation', and in invalidation there is always an 'expose' event, that gives the program time to update the areas of the screen that need 'tidying up'. If I could capture these 'dirty rectangle events', as you put it, and supply them with my own pixels, that would be the ultimate in memory/cpu saving I think. I take it that is not possible yet,
Can it be a feature request?
The player is a deferred display list renderer. It does the rendering in a
whole different portion of the player code and the overhead of calling back
into the actionscript side would probably defeat any gains for what you are
asking for. But you can always file an enhancement request at
The font system does not allow for background colors, but with a fixed width
font, it should be simple enough to draw shapes behind the characters.
I've tried to out-perform the TTF rasterizer by creating a set of
single-line vectors per character and failed because I was moving the
vectors in the ActionScript VM and the rasterizer is working at machine-code
speeds. That's why I suggested trying that. Yes, your code does get JIT'd
to machine code, but it tends not to be as efficient. I was also thinking
of the original IBM PC character mode where you wrote the 8-byte character
and hardware rasterized the character. If you have to use slower
Actionscript to do a lot of processing, it might be better to just set the
character and have the faster player rasterizer do the heavy lifting.
That said, I also know that many Flash games use blits instead of modifying
the vector list because it performs better once the vector list gets large.
So, I think there is a trade-off in there and I don't know of anyone who has
done a terminal emulator in Flash so I can't point you in a particular
direction. I'm just trying to point out how the player is different from
just trying to solve this problem in a native app.
You could also look into using PixelBender to do the rasterizing.