> The example allocates an SDL_Surface large enough to fit the text string each iteration.
Impossible without knowing how much to allocate, which you indicate would require adding a bunch of complexity. However, I am willing to chalk that up to being a typo. Given that we are now calculating how much to allocate on each iteration, where is the meaningful complexity? I see almost no difference between:
while (next()) {
size_t size = measure_text(t);
void *p = malloc(size);
draw_text(p, t);
free(p);
}
and void *p = NULL;
while (next()) {
size_t size = measure_text(t);
void *p = galloc(p, size);
draw_text(p, t);
}
free(p);
>> The example allocates an SDL_Surface large enough to fit the text string each iteration.
> Impossible without knowing how much to allocate
But we do know how much to allocate? The implementation of this example's RenderTextToSurface function would use SDL functions to measure the text, then allocate an SDL_Surface large enough, then draw to that surface.
> I see almost no difference between: (code example) and (code example)
What? Those two code examples aren't even in the same language as the code I showed.
The difference would be between the example I gave earlier:
and: Remember, I'm talking about the API to a Go wrapper around SDL. How the C code would've looked if you wrote it in C is pretty much irrelevant.I have to ask again though, since you ignored me the first time: what do you gain? Text rendering is really really slow compared to memory allocation.