Closed metroite closed 2 years ago
I think the current code doesn't work if show_name
is false (which is the default), because #msg_part_2
is always 0.
Basically this is a line wrap feature. libass has multiple feature requests and even active pull request working on this. I wonder if we should reinvent the wheel, especially in Lua.
I also concern about the performance. The scan of all the text in a popular channel could cause temporary hiccup when a new chat segment is processed, which happens rather randomly from user's perspective. Ideally, if libass could implement this and mpv expose the max length as subtitle config, I will be happy to write some introduction to enable it in README. Of course, we never know when would it happen.
Interesting I didn't know about libass. I have no problems concerning the performance on my high end machine (obviously), but it might be a valid concern so I just casually made this feature toggle able. Doing all this off thread would be desirable.
I agree, libass implementing this would be ideal, but this is a good substitution for a very important feature!
libass is what mpv uses to handle subtitles. All these chat messages are basically subtitles.
a very important feature!
I agree if this is real movie subtitles. However, as we all know, Twitch chat is a bit different. Empirically speaking, if a message is longer than, say 40 characters, most of the time it is just silly spam, instead of a thoughtful essay. I think instead of rigorously scan for a line break and display all that spam message, maybe replacing the tail of that message with an ellipsis is a better idea? The ellipsis can be placed at one of the "delimiters", passing the max_char_length
point. What do you think?
replacing the tail of that message with an ellipsis
While it would be more performant than searching for a suitable position, I don't think that essentially removing information is a good solution. What if it was an important message? Should the user switch back to Twitch to be able to read it?
A good performant compromise would be to always add linebreaks ungracefully, I guess.
My point is that most of the time it is not removing information (since it's repeated spam), as long as the max char is reasonably long. There could be a sweet spot to distinguish between actual meaningful message and spam. I'd also argue that even if we accidentally trim actual message, it's not some big deal. It's just a Twitch chat message after all.
The benefit are better performance and smaller code and complexity, which means less potential bugs.
But of course it's just my experience. I only watch handful of channels. If some channels' chat is largely consisted of long real messages, then wrapping without trim is necessary. Please let me know some examples of such channels if this is the case.
most of the time it is not removing information (since it's repeated spam), as long as the max char is reasonably long
If the max_char_length
ends up too long, it will overlap the stream and if its too short it will shorten relevant non-spam messages. You can see in my image example, user Bromikronwolf didn't spam, yet wrote a long enough message to excessively overlap the stream, if it wasn't for the linebreaks.
let me know some examples of such channels
ProfessorLando would be one such example. There are most probably enough channels out there that engage actively with the chat, where the chat is an integral part of the stream.
Honestly, I can not see any difference in CPU usage. While it would probably be a quantitative and not a qualitative optimization (i.e. just for the sake of it), a more acceptable compromise would be a combination of only ungraceful linebreaks and possibly also ellipsis at the X'th would-be linebreak.
I oppose these compromises as no linebreaks at all would overlap the stream, ungraceful linebreaks make the text harder to read and ellipsis add the danger of removing important information. All add flaws for the sake of a non essential optimization.
These are my takes on the matter, its for you to decide though.
OK. I'll merge your PR with some tweaks and changes.
It also tries to find a suitable position to put a linebreak at. If it can't find one while approaching the maximum width, it will ungracefully add a linebreak like th- is.