taupiqueur_shiny has quit [Remote host closed the connection]
taupiqueur_shiny has joined #foot
taupiqueur_shiny has quit [Remote host closed the connection]
taupiqueur_shiny has joined #foot
qaqland has quit [Ping timeout: 240 seconds]
qaqland has joined #foot
chomwitt has joined #foot
taupiqueur_shiny has quit [Remote host closed the connection]
taupiqueur_shiny has joined #foot
taupiqueur_shiny has quit [Remote host closed the connection]
<dnkl>
Consolatis: it's a good idea, but it has two problems
<dnkl>
first, it'll make VT parsing slower. I _think_ we can get acceptable performance by using a state machine, but that's something that would have to be benchmarked
<dnkl>
second, the colors can't realistically be part of the attribute table
<dnkl>
with underline colors, that means we still need at least 9 bytes (packed) for colors, or 12 bytes if we can't reuse the last byte in each color
<dnkl>
on top of that we'd have the 4 bytes for the character, and the 4 byte attribute index
<dnkl>
i.e 17-20 bytes in total
ollysmith_ has joined #foot
ollysmith has quit [Ping timeout: 248 seconds]
<Consolatis>
<dnkl> second, the colors can't realistically be part of the attribute table
<Consolatis>
care to elaborate on that?
xd1le has joined #foot
<Consolatis>
agree on the first part, the cost of parsing gets higher because of looking up the attribute index
<dnkl>
there are 2^24 combinations for a single color. We can't have that many tables. And, a dynamic, hash-like approach is likely too slow
<Consolatis>
hm.. right. the worst case would be every single pixel having a different attribute set (although that is *highly* unlikely unless we are talking about braille char based image / video encoding)
<Consolatis>
maybe one could use an attribute index like 0xffffffff as an indicator for a different lookup mechanism in those cases, an external array / list which has a pointer to the current cell. that lookup would than be way slower but only be used in num_of_attribute_combinations > x
<Consolatis>
In a usual shell case, I'd assume we'd have like 4 different attribute combinations max like "prompt in bold and some foreground color", "usual text in default foreground and background color", "usual text + bold", "usual text + underline". Maybe add another 4 for "ls" colors. For TUI applications its obviously different but I'd assume its usually also about 100 max.
<rockorager>
Consolatis: I logged how many different styles in aerc and senpai in quick sessions: senpai is 49, aerc is 101 (includes opening a msgviewer and nvim)...good guess!
<rockorager>
This would increase a bit from styled underlines
<rockorager>
Not much i'd imagine
<dnkl>
this still assumes we can do a dynamic table. I don't think we can, not without losing too much performance
<Consolatis>
struct real_attribute attr_map[256] + list (or realloc'd array) with pointers to chars for the slow lookup + using a single byte for the index? :D
<Consolatis>
(cleaning up the not-referenced-anymore indexes will also cost some CPU time though, otherwise after some runtime foot may always have to use the slow lookup)
<Consolatis>
^ [255] rather, 0xff would mean slow lookup
<Consolatis>
s/pointers to chars/pointers to cells/
<dnkl>
for the base table to be static, it'd have to exclude colors. Since most applications do use colors, we'd just end up taking the slow path most of the time
<Consolatis>
I am not sure I follow, the map would get initialized when detecting new state combinations (including its colors)
<Consolatis>
no, I mean its static, (255 elements) but its contents (struct attribute) is not initialized. When a attribute combination is detected and attr_index <= 255: attr_map[++attr_index] = (struct attribute) { .fg = parsed_fg, ..}
<dnkl>
it's dynamic in the sense that you don't know beforehand which attributes a specific index maps to
<Consolatis>
right
<Consolatis>
that would be the more costly during parsing part to figure out the existing index (or if not found) create a new entry
<Consolatis>
costly part*
<dnkl>
exactly. And I'm saying it'll be too costly
<Consolatis>
ah, I see. I got the meaning of "dynamic" wrong then
<Consolatis>
but yeah, memory vs cpu time. Its usually either or the other :)
<dnkl>
at the level we're optimizing the VT parser in foot, it's both :)
<dnkl>
large cells means bad cache behavior
<dnkl>
or, "accessing large data structures during vt parsing"...
<Consolatis>
well, some way forward to store more data in the attributes would still be useful. Currently there is not enough space for even one additional bit.
<Consolatis>
I imagine there will be further features that can't be implemented due to this constrain
<dnkl>
osc-8 is already handled outside the cell structure. Underlines are similar to hyperlinks, and could probably be dealt with in the same way.
<dnkl>
what I'd like to do is generalize the concept a bit, to avoid having to duplicate the osc-8 logic for underlines
<Consolatis>
hm.. I see. So attach the information to the row rather than to each cell
bcheng has quit [Ping timeout: 240 seconds]
bcheng has joined #foot
erectus has quit [Ping timeout: 256 seconds]
erectus has joined #foot
erectus has quit [Remote host closed the connection]
erectus has joined #foot
an3223 has quit [Remote host closed the connection]