Freetype performance

[David M.]

Hi,

I'm using Go freetype (https://github.com/golang/freetype) for a 3D app using OpenGL. At each frame one portion of the text displayed changes, so I call DrawString() and upload the new image to OpenGL. After some profiling I know that the program runs at 350fps without the DrawString() cost, but it goes down to 70 with it. The program is CPU-limited by the freetype code. (I checked that the OpenGL upload and draw aren't the bottleneck).

I'm currently using one texture per line of text, and I only call DrawString when a line of text is changed. My question is, how can I improve the performance of this?

I have some ideas, but I don't like them very much:

• Using one texture per character instead of per line and cache most characters. In this way DrawString will be only called the first times. However, dealing with this is more complex (kerning) and requires more OpenGL draw calls (1 per character instead of 1 per line).
  
• Call DrawString() in a separate goroutine and upload the image to openGL from the main thread after this separated goroutine has completed its work. This should give almost 350fps with texts refreshing at a lower pace. This may work, but it is a work-around after all.

Is the Go freetype library optimized? Should I expect a similar performance from the original C version? Why freetype don't use an internal cache to store most frequent characters?

[Nigel Tao]

On Tue, Oct 25, 2016 at 9:40 PM, David M. <manxi...@gmail.com> wrote:
> Is the Go freetype library optimized? Should I expect a similar performance
> from the original C version? Why freetype don't use an internal cache to
> store most frequent characters?

Go freetype has had some performance work, but not a lot.

I don't have any hard data, but I'd expect it to be e.g. within 2x
worse of the original C version, but not as bad as than 10x worse.

Go freetype should use an internal cache for glyph image masks. Do you
have evidence that this cache is not being used?

Can you link to your code?

The https://blog.golang.org/profiling-go-programs blog post is a
little old, but it should still give some leads on how to profile your
Go code at the function level, not just a coarse "70 fps" number.

[David M.]

I don't know if it is cached or not, but taking 15ms for rendering 300 characters, most of them spaces, size 12 (102 dpi) on a Intel 2500 seems to much.

Here is the profiling:

I call measure string around 3 times per line because the text is colored and I need to know what pixels should I color.

[Nigel Tao]

On Sat, Oct 29, 2016 at 2:11 AM, David M. <manxi...@gmail.com> wrote:
> Here is the profiling:

Ah, in package freetype, face.Glyph results (glyph images) are cached
but face.GlyphAdvance and face.Kern results are not.

Thanks for the bug report, I filed https://github.com/golang/freetype/issues/42