On my stupid benchmark: having tyfuzz parse a 628MB text file (few times
war and peace concatenated) over 10 sessions, it went from 15.2MB/s to
16.8MB/s \o/ That's a 10.5% improvement!
yes. it's still inefficient because we transfer in ascii-ized nibbles
(4 bits) within a utf8 stream that becoems a 32bit per char unicode
buffer then back to utf8 before being "parsed" as a command etc. etc.
... it's not brilliant for transferring binary data. it's horrible
actually. but at least i've dropped overhead for some of the large
escape handling code.
this increases buffer size to 32k per block sent, and have the
terminal escape/buffer handling track if a zero byte exists in the
buffer at all to avoid hunting for one if none is there, making
terminology escape handling much more efficient for large escapes and
buffers.
In the backlog, every cell but the last one has the autowrapped flag set.
_termpty_cellrow_from_beacon_get() now returns a length in the
"screen space".
we memcpy'd the currenty size over, so if prev size was smaller - this
was wrong and valgrind threw a complaint. also the rounding seems
utterly bizarre. it looks like it was meant to round up to the nearest
"lot of 8 tabs" so actually do that... which makes is easy to pass in
old width nicely now to fix the problem.
@fix
i've noticed that the exe cb tries to drain the pty fd but reads
return -1 with EAGAIN so terminology just spins forever in cpu trying
to drain a buffer that does not drain, so make a special case on exe
exit - drain until there just is nothing else to read then give up.
@fix
if (len <= 0)
in _cb_fd_read() is ALWAYS coming up with len < 0 for me and that'd
be LOGICAL... eg if read() returns an error (something ok to allow us
to continue) and so my terminal content NEVER appears - because
terminology is returning false from the fb handler asking it to be
deleted. this is wrong so put it inside #ifdef of fuzzing so it
doesn't affect "normal people". i still think it is broken tho... but
at least i have my terminal back now.