Soundbomber's picture

Is TextPrinter inherently slow?

A couple of questions:
1 - I recently added some text to my 3D views resulting in slower rendering. I only added a couple of words, but at high magnifications, the render speed was noticably slower. Is TextPrinter inherently slow?
2 - Can antilaliasing be used with TextPrinter?

[Edit] Is TextPrinter the only way to go for 2D text in a 3D environment?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Have you tried zooming with TextPrinter? Zooming out by even 5% will make small text illegible. Zooming in is very very ugly. See here for screenshots comparing Valve's method with plain textured fonts ala TextPrinter. Link also provides code for distance field calculations.

My impressions on Valve's method:

  • The brute force distance field algorithm is easy to implement but slow.
  • Needs large source images (rule of thumb: source image should be 8x larger than the output).
  • Acceptable to good quality for a large range of text sizes (16pt - 96pt). Quality falls quickly for small sizes and artifacts become visible for larger sizes.
  • Very easy to add text effects, such as glow, outlines, shadows, etc.

A faster algorithm for DF calculation could eliminate the need for preprocessing.

Soundbomber's picture

This (Valves paper) sounds daunting for a noob like me to attempt - I wouldnt even know how to create the distance field bitmap let alone anything else!

the Fiddler's picture

For the record, this is what happens if you try to zoom plain textured fonts:

ZoomableText.png65.73 KB
objarni's picture

Is that rendering using trilinear filters?

Soundbomber: are you doing "StarWars"-like zooming ("perspective"), or simply scaling?

The NVidia technique looks interesting to someone versed in shaders.

Soundbomber's picture

Just scaling. I cant believe simple 2D text is so difficult to achieve!
What is the NVidia technique? (Not that I'm even versed in shaders!!!!!)

Soundbomber's picture

Does anyone know why the OpenTK control in double buffer mode is incompatible with GDI+?

the Fiddler's picture

GDI or GDI+? Starting with Vista, you can no longer mix GDI and OpenGL on the same window. I have no idea if you can mix GDI+ and OpenGL (you probably cannot).

If you actually can mix the two, you'll have to redraw text after every call to SwapBuffers.

Soundbomber's picture

I have tried drawing on the controls surface (calling invalidate after every swapbuffers) and you can see the text, but I get a flickering effect.
Its as if the text is only being drawn half the time - maybe when the buffer is/isn't being used?
I have even tried overlaying a transparent control and drawing on its surface but I get the same flickering effect (very annoying).
If I overlay my text so it lies half on the OpenTK control and half off, the portion that overlaps flickers and the other doesnt!
I was thinking that maybe I could interupt a windows message or something, but not having much luck so far.
Pity because GDI+ offers everything I need i.e. perfect text at any magnification (fast too!)
Are there any overrides for the OpenTK control that may help?

the Fiddler's picture

No, no magic bullet to make this work. This is a Windows limitation, not an OpenTK one. It is akin to using Direct3D to draw on an OpenGL surface - don't expect it to work.

Potential solution: use GDI+ to draw text on a Bitmap, upload the bitmap as a texture and overlay the texture over the screen. Word of warning: uploading a 1920x1200 texture will be very slow.

Soundbomber's picture

Thanks, but this thread started with the text rendering too slow :)
If I could just figure out a way to stop my overlayed transparent control from flickering I would have cracked it.
Oh well, back to the drawing board!