Re: [hackers] [dmenu|libsl][PATCH] optimize drw_text() for large strings

From: NRK <nrk_AT_disroot.org>
Date: Sat, 19 Mar 2022 20:47:51 +0600

On Sat, Mar 19, 2022 at 11:06:25AM +0100, Stein Gunnar Bakkeby wrote:
> Given that it is asking XftTextExtentsUtf8 to calculate the width of every
> character every time this is checked I assume that it would be less
> performant (though possibly not so easy to measure).

Hi Bakkeby,

You can test this patch with the following script:

        for _ in $(seq 20); do
                cat /dev/urandom | base64 | tr -d '\n' | head -c 1000000
        echo
        done | ./dmenu -l 10

Try moving up and down, without the patch there should be noticeable
amount of lag; with the patch it's pretty much instant for me.

> Now as for the patch. It is meant as a performance improvement when strings
> are too long to fit and I can see how it might be an improvement when the
> string is just a little bit too long for the drawable area, but what if it
> is twice as long?

I think you've gotten it backwards, this patch should *faster* if the
string is too long, since we're incrementing up to w instead of
decerementing down it it.

> In an attempt to address some of these issues I played around with moving
> the XftTextExtentsUtf8 call to the section before that calculates
> utf8strlen and maintaining the ew variable manually. In practice means that
> the call to XftTextExtentsUtf8 is made for every single UTF-8 character
> (but only one character at a time).
>
> In addition to this I recorded the width of "..." to calculate and keep
> track of the last full UTF-8 character where the ellipsis would still fit
> so that I know where to go back to should the ellipsis need to be drawn.
>
> I can show the implementation of that should there be any interest.

Sure, I'm interested in seeing what you've come up with, especially
since I've been thinking of making some changes to drw_text() myself.

- NRK
Received on Sat Mar 19 2022 - 15:47:51 CET