How to draw readable tiny text quickly

Question

In developing a flash-based memory manager, I need to be able to view large quantities of data. With my eyes and monitor resolution, I can read hand-drawn 3x5 letters on a 4x6 matrix without too much difficulty, but none of the system TrueType fonts render optimally at that size. I've tried writing code to draw font shapes to off-screen bitmaps, and then use DrawImage to copy those bitmaps to the screen, but I can't get good performance. This is for development, not production, so performance doesn't have to be absolutely optimal, but I don't want to spend too long waiting for screens of data to refresh.

What would be the best way of either making .net display a font which is pixel-perfect what I want, or else building a bitmap out of lots of little pieces quickly? I'm using vb.net, so I can't simply generate a bitmap as a byte array and pass that to the Bitmap constructor unless someone can show me how to convert an array into an IntPtr.

Answer 1

I'd find an existing 3x5 pixel font, and use it to draw text. Would this work? http://www.pimpyourfont.com/font-12368-Pixelzim-3x5

Answer 2

I'd use a font editor to put your individual bitmaps together into a bitmapped font, then display your text in that font.

Answer 3

I would suggest creating the font yourself. There are several good font editors out there:

Font Forge -- http://fontforge.sourceforge.net/

FontCreator -- http://www.high-logic.com/fontcreator.html

Type Light -- http://cr8.netfirms.com/typelight.html

TTFEdit -- http://sourceforge.net/projects/ttfedit/

DoubleType -- http://doubletype.org/wiki/index.php/DoubleType

Answer 4

To draw readable text at that size you should consider subpixel rendering. Take a look at these examples.

Answer 5

My thanks to those who answered. I had been overcomplicating things in the hopes of improving responsiveness, but was just making things worse. I had separate routines to handle a change to an on-screen item and to handle screen redraws. For the each item I kept thee objects representing the current state, the state drawn on screen, and state drawn in a backing bitmap. When an item that had already been drawn on-screen changed, I would draw the changed version directly to the screen (using Control.CreateGraphics) without invalidating anything. When a portion of the screen was invalidated and needed to be redrawn, I would update the items on the backing bitmap and then copy the backing bitmap to the screen. My goal was to avoid copying the entire backing bitmap to the screen every time an item changed. My expectation was that screen redraws due to region invalidation would not generally be interspersed with item updates, and that updating an item by drawing to the screen would be faster than drawing to an off-screen bitmap and copying that to the screen.

Performance improved considerably when I made the item-changed code draw to the off-screen bitmap and invalidate the region containing the item. It seems there's a substantial per-drawing-operation penalty when copying bitmaps to the screen that does not exist when copying to another off-screen bitmap. Thus, copying twenty little bitmaps into pieces of a big one, invalidating the areas of the on-screen representation where those little bitmaps appear, and then copying the whole big bitmap to the screen (clipped to the invalidated areas) is much faster than simply throwing the little bitmaps on the screen.