Using freetype-go as a back end for sdl-ttf

[velovix]

Making an SDL2 implementation for Go would be great, but we probably shouldn't reinvent the wheel when we don't have to. In the case of sdl-ttf, that would be a particularly tough wheel to reinvent. What if we used freetype-go as the back end? I took a quick look at the API and it seems like most of the features we need are in there with a few exceptions (checking ascent/descent, fixed-width detection, etc) that I may have missed. Has anybody else looked into this?

[jangler]

My thoughts on this:

• I've had weird problems with sdl_ttf, like certain glyphs randomly disappearing and rendered text being zero width when it shouldn't be. Maybe these problems could be fixed in a reimplementation, but I'd be happy to consider an alternative solution.
• I actually tried using freetype-go as a replacement for sdl_ttf because of these problems, but it was prohibitively slow. I don't know whether this was because of the freetype-go library itself, the way I was using it, or the context in which I was using it (xgb). I wouldn't be surprised if all three were factors, but if I can't use freetype-go in the same way that I use sdl_ttf and get similar performance, then it's unacceptable as a replacement IMO (for the purposes of a SDL2 library).

More research is probably warranted.

Edit: FWIW, sdl_ttf uses freetype2 as a back-end anyway, and we certainly wouldn't want to have to port that to Go as well, so freetype-go would be the obvious direction to explore in any case.

[velovix]

I agree that speed should be a pretty big concern in this case. I didn't know that sdl_ttf used freetype2, so that might make the transition easier if freetype-go is performant enough. I'll look into this.

[velovix]

Okay, it looks like freetype-go is not in any state to serve as our back end, simply because it's too lacking in features. That said, it looks like developers on golang.org/x/exp/shiny want to help improve the library as seen here.

"A secondary goal is to drive development of the Freetype Go port - it has some basic functionality but also some long-standing known deficiencies. Writing a quality GUI text editor is again a substantial amount of work, and I don't intend to build one, but I intend that working on shiny will push the Freetype Go library to be good enough to let someone or some team do exactly that, if they had the time and inclination."

[DeedleFake]

It's been about 11 months since the last post in this discussion. Has golang/freetype gotten any better since then? Is this more feasible now? I'm working on a project using SDL2, and I'm running into problems with glyphs randomly not rendering. I get errors like the following:

Failed to render "Th": Text has zero width

So far as I can tell, it's a pretty common problem with SDL2_ttf. The most annoying part is that it seems to happen completely at random. Sometimes it works, and sometimes it doesn't.

[veeableful]

I hadn't followed this discussion but if this issue can't be fixed with SDL2, I'll have a go at writing the code that use the Go freetype library.

In the meantime, is it possible for you to share a small runnable code that reproduce the issue? It seems like the only other similar problem I found is in another binding for D lang: http://stackoverflow.com/questions/26956658/sdl-ttf-rendertext-blended-fails-randomly.

I added a test file called sdl_ttf_test.go at the ttf directory which you can run by executing go test -v at the directory. It simply executes ttf.RenderUTF8_Solid() multiple times on random strings. It doesn't seem to reproduce the issue though :(

[DeedleFake]

I have not been able to reproduce the problem consistently. It happens a lot, but sometimes it doesn't happen at all. For some bizarre reason, it seems to happen far more often when using the race detector, but even then it doesn't happen sometimes. I think it may have to do with multithreading issues, but I'm not sure.

I looked into golang/freetype. It looks pretty clean and easy to use, but the issue is that it renders, not surprisingly, to a draw.Image. Would it be possible to provide a way to make an sdl.Surface and/or sdl.Texture implement draw.Image, either directly or as some kind of wrapper type that adds the methods? I've done it before in my own SDL bindings, but I'm not sure how efficient it was, and I don't think it worked with very many pixel formats.

Edit: On a side note, I was looking through sdl.Surface's methods and I noticed that the Data() method returns an unsafe.Pointer. Returning an unsafe.Pointer directly is usually considered a bad practice. Should I take a look through for others and submit a pull request to change them to return a uintptr?

[roglew]

I'm really late to the party but I wanted to reply about the error:

Failed to render "Th": Text has zero width

I was having this problem and it was due to using a RWFromMem wrapped around a ttf font I loaded into memory previously. It looks like the resulting RWOps didn't have any references to the byte slice that I used to create the RWOps and it was getting garbage collected and throwing the zero width error later.