noteness has quit [Read error: Connection reset by peer]
an3223 has quit [Read error: Connection reset by peer]
kevr has quit [Read error: Connection reset by peer]
caveman has quit [Read error: Connection reset by peer]
caveman has joined #foot
kevr has joined #foot
noteness has joined #foot
an3223 has joined #foot
an3223 has quit [Ping timeout: 240 seconds]
an3223 has joined #foot
noteness has quit [Read error: Connection reset by peer]
kevr has quit [Write error: Connection reset by peer]
an3223 has quit [Write error: Connection reset by peer]
caveman has quit [Read error: Connection reset by peer]
kevr has joined #foot
noteness has joined #foot
an3223 has joined #foot
caveman has joined #foot
an3223 has quit [Ping timeout: 240 seconds]
an3223 has joined #foot
caveman has quit [Remote host closed the connection]
caveman has joined #foot
kevr has quit [Remote host closed the connection]
kevr has joined #foot
an3223 has quit [Remote host closed the connection]
an3223 has joined #foot
bgs has quit [Read error: Connection reset by peer]
bgs has joined #foot
teraspin has joined #foot
cbb has joined #foot
<cbb>
jvoisin: dnkl: #954 is looking good now
<cbb>
...but
<cbb>
I was just testing chafa again under: bld/foot -otweak.sixel=false
<cbb>
and it seems to take quite a bit longer than usual
<cbb>
even though nothing is printed
<dnkl>
cbb: just a guess, but chafa may be waiting for a response to sixel query
teraspin has quit [Quit: Leaving]
<dnkl>
That we disable when sixel=false
<cbb>
I think I've narrowed it down to the realloc() in ensure_size()
<dnkl>
Ah :)
<cbb>
it seems to be growing the buffer by 128 bytes at a time
<cbb>
up to a maximum of 1644160 bytes in my test
<dnkl>
Oooh... Because now we're not consuming the sixel data
<dnkl>
So, instead of disabling the sixel escape, perhaps we should redirect its "put" function when sixel=false
<dnkl>
And probably rewrite DSC handling, so that we don't allocate large buffers for all unrecognized sequences...
<cbb>
yeah, I was just thinking the same thing
<cbb>
and perhaps also grow the buffer with e.g. size <<= 1
<cbb>
although I'm not sure if there's anything else that produces a lot of DCS data?
<dnkl>
Don't think there is. I _think_ BSU/ESU are the only escapes that make use of this buffer? If so, maybe they should be rewritten to use a "put" function instead
<cbb>
there seems to be XTGETTCAP and DECRQSS too
<cbb>
but I think neither needs a large buffer
<dnkl>
Right. Maybe use a fixed size buffer instead, and make sure we just throw away data for sequences we don't recognize
<cbb>
yeah, sounds like a good idea
<cbb>
I'm not sure if there's a simple way to conclude #954 though...
<cbb>
maybe just use a no-op put handler and tackle the rewriting in a separate PR?
<dnkl>
cbb: either that, or stall the PR until the rewrite is done...
Arnavion has quit [Ping timeout: 256 seconds]
Arnavion has joined #foot
cvmn has joined #foot
cbb has quit [Ping timeout: 252 seconds]
cbb has joined #foot
noteness has quit [Remote host closed the connection]
noteness has joined #foot
cabal704 has joined #foot
cabal704 has quit [Ping timeout: 260 seconds]
cabal704 has joined #foot
<cbb>
dnkl: I just noticed a similar buffer realloc issue exists for osc_ensure_size() too
trav81787 has joined #foot
travankor has quit [Remote host closed the connection]
<cbb>
it's growing by a fixed 128 bytes, instead of exponentially
<cbb>
so if I use OSC 52 to copy the whole contents of terminal.c, for example
<cbb>
it does 1120 reallocs
<cbb>
although it doesn't seem to cause noticeable lag like the other case
jvoisin has quit [Ping timeout: 256 seconds]
<cbb>
ah never mind, that's just because of the size difference
jvoisin has joined #foot
<cbb>
For OSC, I don't think we have the option of using a fixed-size buffer like with DCS
<dnkl>
cbb: agreed. Growing it exponentially sounds like the best option
<dnkl>
I'll try to work on it tomorrow. Unless you beat me to it :)
<cbb>
I can put a patch together
<cbb>
I'm wondering if it'd also make sense to have a (configurable) limit on the size