Mushclient renders text to screen twice for trigger re-colouring?

Just wondering if this is a "It must be this way because..." thing, but I notice that Mushclient actually draws all incoming text to the screen (renders all the text on-screen including the newly received lines), THEN lets triggers do all their re-colouring, then will re-render the screen again with any new styles/re-colourings set by triggers. I know SOMETHING like this must be happening as when a lot of text is incoming I will see flashes of the original (bright) colours of lines sent by the mud for a tiny moment before it gets re-coloured.

So just wondering - does it have to be this way? Or is there a potential optimisation where Mushclient could hold the styles until all triggers have set their re-colourings, then only finally render the line to output afterwards?

Rendering every line of text twice if there's a lot of re-colouring going on just feels like it could be causing unnecessary slowdown (especially on my VERY old machine).

Edit: I also see "omit from output" gets rendered to screen briefly, then deleted from the screen (screen re-rendered without it and text jumping back down again). Perhaps Mushclient should "hold" the current line, let all triggers set their omit flags, re-colouring flags, then when all triggers have been processed, only *THEN* render the line?

Your slow machine is contributing to it being noticed. :)

The thing is, the very first version of MUSHclient (20 years ago) did exactly that. It showed the line after it got a linefeed.

http://www.gammon.com.au/scripts/showrelnote.php?version=0.64&productid=0

Here's the problem: For prompting MUDs (where you get prompted for a character name) you didn't see the prompt. Eg.



So you would connect and wonder why nothing was happening (because that line wasn't displayed). So it was changed to display even a partial line to the window.

However now you have the issue of triggers. Triggers can't realistically match until the whole line arrives. There is no guarantee that each line comes in a single "packet" of data from the MUD, so you can't assume end-of-packet is end-of-line. So for example, if you wanted a trigger that matched on "Press (Enter) to continue" and what arrived from the MUD was "Press (En" then it wouldn't match. And then in the next packet you get "ter) to continue" which also doesn't match.

So, trigger matching has to be deferred to until a newline arrives.

Put these together and you get what you observe. On a fast machine this happens so quickly it is hard to notice it.

Ooooh, that is all very interesting! I do realise (and acknowledge!) my machine is very slow, it's ancient, and was already ancient when I bought it cheap 2nd hand (though it is completely "clean" - fresh install, all bloatware removed, only a browser with a few tabs, and a text editor ever running alongside it). It actually chugs if I let Mushclient buffer more than 10k lines of text (which should be nothing on any other machine!)... so didn't really expect such a minor optimisation to be much of a priority for 99% of users anyway... but your answer explains it too, that does make sense - particularly about the packet splitting stuff!

Thanks for the speedy insight, Nick!

Maybe only show a partial line after a certain amount of delay (200ms? 500ms? 1000ms?). Reset the delay timer on every new packet.

I don't like timing-based things. Imagine if you had a dialog box that presumed you replied "OK" after waiting 5 seconds, when you were actually checking on something in a different room.

I think this is different, because it's not forcing a user action, just choosing to display an edge case in a way that should still be just as functional without causing this other problem.

I think we can assume that partial lines are only ever worth showing when either waiting for user input or in extremely low data throughput conditions. Otherwise the remaining part of the line would be imminently forthcoming anyway. In both of those cases, a small delay before updating the screen is acceptable if it would prevent rendering lines twice.

I don't like arbitrary delays because they're arbitrary, but I think this one would be some marginal improvement at worst even if it doesn't always work.

If the data arrives quickly you shouldn't really see it twice because redrawing the screen is a comparatively low-priority event.

I do see the omitted lines (that briefly appear and then immediately vanish, with the screen jumping down and up as it deletes the line) very frequently, and the brief-flashes of colour of the original lines before the triggers re-colour them frequently too. It's only a split-second thing, but when your eyes are watching the bottom of the screen to read all lines as they come in, it can be jarring.

As I said before though, I do realise I have a very old and slow laptop (netbook in fact), that I can't do very much on, so I'm not at all expecting any painful/bizarre optimisations to be done for people like me, I don't know how many Mushclient users really have particularly low-spec machines - and it's not something I'm crying about at all - I live with it quite happily, I just thought if it WAS a simple fix, it would have been a nice one - but which while I don't really understand everything being said above, it sounds like it might not be a simple thing at all!

Don't feel too bad about it. I ask Nick for performance optimizations that nobody else needs all the time, and we're still friends! Usually it's because I'm doing something insane that nobody else has done before.