07:27 <Arsen> I might've found a regression: if there's lots of scrollback, resizing can lead to a crash

07:27 <Arsen> on foot version: 1.13.1 -pgo +ime +graphemes -assertions

07:27 <Arsen> notably I set [scrollback] lines=50000

07:28 <Arsen> actually, not sure if it's a regression

07:28 <Arsen> setting that could've been what exposed it

07:28 <Arsen> yeah, it's fine on lower values

07:30 <dnkl> Arsen: this is sort of known, but had been near impossible to reproduce. I've *never* seen it myself.

07:30 <Arsen> oh hmm

07:30 <dnkl> one cause for the crash was fixed in 1.13.1

07:31 <Arsen> tried a super high ines value?

07:31 <Arsen> lines*

07:31 <dnkl> tried many things

07:31 <dnkl> :)

07:31 <Arsen> what if it's kde specific

07:31 <dnkl> if you have a sure-way to reproduce, let me know.

07:31 <dnkl> very unlikely

07:31 <Arsen> I can reprod on: info: main.c:421: version: 1.13.1-40-gbb02b319 (Sep 30 2022, branch 'master') -pgo +ime +graphemes +assertions btw

07:32 <dnkl> can you get a backtrace from a debug build?

07:32 <Arsen> and it's certainly reproducible on my machine: run foot, run yes in it, rapidly resize horizontally

07:32 <Arsen> it doesn't crash, actually

07:32 <Arsen> Error sending request: Broken pipe

07:32 <Arsen> ... and does it's normal shutdown

07:32 <Arsen> err: wayland.c:1236: failed to dispatch pending Wayland events: Broken pipe

07:32 <dnkl> ok, then I think I know what it is

07:33 <dnkl> with a large scrollback, text reflow takes time

07:33 <dnkl> in this case, enough time that we don't process the incoming mouse motion events quickly enough

07:33 <dnkl> the compositor fills the socket and then kills the connection

07:33 <Arsen> that would make sense, yeah

07:34 <Arsen> running with WAYLAND_DEBUG=1, I see that it's still processing a bunch of xdg_toplevel@27.configure(...)s after the compositor closed the window already

07:36 <dnkl> difficult problem to solve. With literally can't receive the Wayland events while resizing the window.

07:38 <Arsen> my (perhaps too abstract to be useless) idea for a solution is reflowing text only when the user is trying to view it from scrollback

07:38 <Arsen> though, text handling is one of those thing's I'm especially bad at, so I can't tell how possible it'd be to implement that

07:39 <Arsen> s/thing's/things

07:39 <dnkl> won't work. reflow has to start from the start of the scrollback. you can't do a partial reflow starting at the bottom

07:40 <w0rm> dnkl: how about delaying reflow when resize happens

07:40 <dnkl> might be possible to stash the original contents when a resize is started, and only truncate, not reflow, *while* resizing. and then reflow at the end, when resize is done

07:40 <dnkl> w0rm: 😂

07:40 <Arnavion> Not reflowing until the resize ends would be very annoying

07:41 <w0rm> yeah, I suppose so...

07:41 <dnkl> yeah, I know...

07:41 <Arnavion> Can the reflow algorithm work backwards one \n-delineated span at a time?

07:42 <Arsen> maybe only reflowing top_of_screen - row_number / 2 lines and letting the rest get reflown properly later?

07:42 <dnkl> we could handle it the same way we handle WINSZCH; do it after a timeout. You can see the effect of this by quickly resizing the window in e.g vim.

07:42 <Arsen> with that being hopefully enough to hide any bad resizing

07:42 <Arsen> er, I put that formula poorly

07:43 <Arsen> start from top_of_screen - row_number / 2

07:43 <dnkl> the problem is how to track the source content over multiple quick resizes, when only reflowing parts of it

07:45 <dnkl> I think the "delay" solution can wor, if the delay is sufficient small. I could try writing up a POC

07:46 <Arsen> by operating on a copy maybe? with that hopefully not being too large to copy quickly

07:46 <Arsen> and only reflowing the whole thing on a delay

07:48 <dnkl> Yeah, keep a copy of the original content *while* resizing. First iteration of the solution would just truncate, then reflow after a delay, or when resize is done.

07:49 <dnkl> Later iterations can experiment with partial reflow, to improve user experience

07:49 <Arsen> yeah, that's fair

07:49 <Arsen> thanks btw

07:49 <dnkl> copying is not an issue - we're already doing that. It's just a matter of not free:ing the original content

13:00 <dnkl> Arsen: fwiw, I just tested kitty, and it uses the exact same method.

13:02 <dnkl> I have a POC the does work, and greatly improves performance. For very large grids, there's still a noticable delay when starting the resize, caused by copying the original grid. I think we can get rid of that too, but requires more work