Silly performance bug in XDrawImageString{,16}
This was noted in !38 (merged), but chunking the request into blocks of 255 seems like a self-inflicted injury to me. AFAICT it's done this since about 1987, and I imagine the motivation was to avoid excessive buffering/latency/memory usage. However, a 255-character-long string of a 6x8 terminal font would be 1530 pixels wide, which is likely to be greater than the width of the display for any machine where drawing 255 characters takes perceptible amounts of time.
I'm typing this from a 2.2GHz Skylake laptop, where x11perf -pointer
says I can do about 70k round trips per second. For a 50-line terminal that exceeds the batch width you'd add something like a millisecond to total drawing time on the local machine. But the ping time to my wireless router is about 2ms in the best case, so across the network a 50-line terminal would need another 100ms to fully redraw.
So... maybe just delete the batching? Or if you want to be clever while still self-scaling, set the batch size to be the width of the root window divided by (the font's minimum character width || 1).
cc @dickey