On Thu, Jun 3, 2021 at 1:40 AM Ian MacArthur wrote:
> 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.

Sure, I've been doing this a lot lately, but I'm clumsy with this kind
of thing so mistakes are possible.  And in fact, I took a second look
and I think you are correct.  Text drawing takes up around 0.00002 and
0.00004 per (small) string, and though I'm calling fl_draw 1542 times
to draw at one zoom level (admittedly it's a lot), the total time is
only 0.0393, which is not much compared to the whole time of 0.7528.

So I think I wrongly accused text drawing here. I was misled by my
metrics which didn't adequately bracket it, and tempted by caching
since there are many  small text fragments drawn from a small
vocabulary.  Caching may still be useful, but it's clearly not the big
problem here.

Some further digging shows that most of the time is taken up by
Fl_RGB_Surface::image (0.0288), with a smaller chunk taken by
allocating the Fl_RGB_Surface in the first place (0.0152).  I'm a bit
surprised that even allocation takes so long, but these wind up being
7-16mb chunks, so they're oversized... this is not for text, but the
result of an earlier attempt to speed up scrolling by caching window
contents.  That attempt worked, but has clearly has side-effects at
high zoom levels where the overdraw is extreme.  My original plan was
to split the scroll cache into tiles so I'm not drawing much outside
the visible area, and it looks like I'll have to do that after all.

Still, the apparent multiple copies in the Fl_Surface_Image -> driver
chain is interesting, especially if the allocation is so expensive.
I'll look into if it's really doing copies, and if so, if it would be
possible to reduce that.

On Thu, Jun 3, 2021 at 11:29 AM Bill Spitzak wrote:
>
> If your image consists entirely of black text where it is transparent everywhere it is not black, then in fact the color channels would be black everywhere. What you are getting on the edges of your letters sounds like it is gray (with a partial alpha channel) and thus lighter than black, and this is why the letters look thinner.

I'll bet that's it!  Since the black text has been drawn on a white
background, it's effectively premultiplied against white, and by using
it as alpha I'm applying it twice.  I set the image to all black and
used `0xff - red` and got exactly what I expected.  Unfortunately I'll
probably discard this caching attempt based on the input from Ian, but
I'll keep this in mind if I decide to cache text after all.

-- 
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CACbaDy6QsYF8NDhz107deOfvPHgzYHPcikh5rc1rw2Qkhe43cQ%40mail.gmail.com.