[fltk.general] Re: Fl_Image_Surface, alpha, caching fl_draw - Forums

On Thursday, 3 June 2021 at 07:24:13 UTC+1 qdunkan wrote:

Hi, I recently had the clever idea to accelerate drawing of text in my
app by caching the output of the fl_draw in an image. I used
Fl_Image_Surface, and it almost works... except the output has no
alpha channel. Since the text is always black, I made a copy of the
image and inferred an alpha with `0xff - avg(r, g, b)` but the results
are noticeably thinner than the native antialiased fl_draw output.
The black is still entirely opaque as it should be, but the
transparent parts are more transparent.

Hi Evan,

Ummm... text rendering is often pretty swift, on most platforms, so I'd need to see some actual hard metrics before I bothered with caching.

That said, if you have text rendered via pango (rather than just XFT) on *nix systems, that is slower than "stock" if it has to do a lot of font substitutions to render the full text.

Is the alpha channel non-linear in some way? Or is `1 - avg(r, g, b)`
too simplistic?

Probably a bit too simplistic...

Is this just for a "regular window? It's not for a GL window or anything?

The text for GL windows is already cached, since there's no "GL native" mechanism for rendering strings of text.

WIN32 has a GL text interface that works pretty well, so we do use that directly, but on both OSX/macOS and X11 we use a scheme where we render the AA text into a cache of little GL buffers and then reuse those cached text images when redrawing those strings.

This works pretty well, supports the "full" Unicode space (at least as well as the fonts I have, anyway) and seems reasonably swift in practice - so if you are in a GL window, that should already be cached and I doubt there'd be much benefit from a further level of caching there.

If this is for a non-GL context, then you could try looking at the GL caching scheme and see how the textures are constructed there, in case that is informative for what you are truing to do.

The X11 case is probably the more generic (the OSX path uses some Apple-isms, or at least used to, I'm not certain if it still does) and at some point in the past I understood that code (since I wrote chunks of it) but it is complicated...