https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS

Reported by Santtu Lakkala <inz@inz.fi>, thanks!

we already need to know the string length since `cursor` needs to be adjusted. so just calculate the length beforehand and use `memcpy` to copy exactly as much as needed (as opposed to `strncpy` which always writes `n` bytes).

currently readstdin(): - fgets() into a local buffer, - strchr() the buffer to eleminate the newline - stdups() the buffer into items a simpler way is to just use getline(3), which will do the allocation for us; eliminating the need for stdup()-ing. additionally getline returns back the amount of bytes read, which eliminates the need for strchr()-ing to find the newline.

Always use ~30% of the monitor width for the input in horizontal mode. Patch adapted from NRK patches. This also does not calculate inputw when using vertical mode anymore (because the code is removed).

additionally, ellipsis_width (which shouldn't change) is made static to avoid re-calculating it on each drw_text() call.

this patch just rejects *any* 0 width draws, which is surely an error by the caller. this also guards against cases where the width is too small for the ellipsis to fit, so ellipsis_w will remain 0. reported by Bakkeby <bakkeby@gmail.com>

From commit 6818e07291f3b2913e687c8ec3d3fe4711724050 by NRK, thanks

This reverts commit 6818e07291f3b2913e687c8ec3d3fe4711724050. This broke keys such as ^W to delete-backward-word

while i was timing the performance issue, i noticed that there was lots of random redrawing going on. turns out there were coming from here; if someone presses CTRL/ALT etc without pressing anything else, nothing will be inserted, so nothing will change. but the code will `break`, go down and do a needless redraw. this patch changes it to simply return if the keypress iscntrl() also avoid potential UB by casting *buf into an unsigned char.

`items` itself is not checked for NULL as calling free on NULL is defined to be a no-op.

this was the last piece of the puzzle, the case where we can't find any font to draw the codepoint. in such cases, we use XftFontMatch() which is INSANELY slow. but that's not the real problem. the real problem was we were continuously trying to match the same thing over and over again. this patch introduces a small cache, which keeps track a couple codepoints for which we know we won't find any matches. with this, i can dump lots of emojies into dmenu where some of them don't have any matching font, and still not have dmenu lag insanely or FREEZE completely when scrolling up and down. this also improves startup time, which will of course depend on the system and all installed fonts; but on my system and test case i see the following startup time drop: before -> after 60ms -> 34ms

a massive amount of time inside readstdin() is spent trying to get the max input width and then put it into inputw, only for it to get clamped down to mw/3 inside setup(). it makes more sense to calculate inputw inside setup() once we have mw available. similar to the last patch, i see noticeable startup performance improvement: before -> after 160ms -> 60ms additionally this will take fallback fonts into account compared to the previous version, so it's not only more performant but also more correct.

this replaces inefficient pattern of `MIN(TEXTW(..), n)` with drw_fontset_getwidth_clamp() instead, which is far more efficient when we only want up to a certain width. dumping a decently sized (unicode) emoji file into dmenu, I see the startup time drop significantly with this patch. before -> after 360ms -> 160ms this should also noticeably improve input latency (responsiveness) given that calcoffsets() and drawmenu() are pretty hot functions.

getting the width of a string is an O(n) operation, and in many cases users only care about getting the width upto a certain number. instead of calling drw_fontset_getwidth() and *then* clamping the result, this patch introduces drw_fontset_getwidth_clamp() function, similar to strnlen(), which will stop once we reach n. the `invert` parameter was overloaded internally to preserve the API, however library users should be calling drw_fontset_getwidth_clamp() and not depend upon internal behavior of drw_text().

this patch makes some non-trivial changes, which significantly improves the performance of drawing large strings as well as fixes any issues regarding the printing of the ellipsis when string gets truncated. * performance: before there were two O(n) loops, one which finds how long we can go without changing font, and the second loop would (incorrectly) truncate the string if it's too big. this patch merges the overflow calculation into the first loop and exits out when overflow is detected. when dumping lots of emojies into dmenu, i see some noticeable startup time improvement: before -> after 460ms -> 360ms input latency when scrolling up/down is also noticeably better and can be tested with the following: for _ in $(seq 20); do cat /dev/urandom | base64 | tr -d '\n' | head -c 1000000 echo done | ./dmenu -l 10 * correctness: the previous version would incorrectly assumed single byte chars and would overwrite them with '.' , this caused a whole bunch of obvious problems, including the ellipsis not getting rendered if then font changed. in addition to exiting out when we detect overflow, this patch also keeps track of the last x-position where the ellipsis would fit. if we detect overflow, we simply make a recursing call to drw_text() at the ellipsis_x position and overwrite what was there. so now the ellipsis will always be printed properly, regardless of weather the font changes or if the string is single byte char or not. the idea of rendering the ellipsis on top incase of overflow was from Bakkeby <bakkeby@gmail.com>, thanks! however the original patch had some issues incorrectly truncating the prompt (-p flag) and cutting off emojies. those have been fixed in here.

Reported by Prathu Baronia <prathu.baronia@praton.me>, patch slightly changed. Thanks!

... compared to the old cistrstr(). Thanks for the feedback!