[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Mushclient renders text to screen twice for trigger re-colouring?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

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

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Gsmith   (14 posts)  [Biography] bio
Date Thu 24 Nov 2016 09:47 AM (UTC)

Amended on Thu 24 Nov 2016 09:50 AM (UTC) by Gsmith

Message
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?
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Thu 24 Nov 2016 08:26 PM (UTC)
Message
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.


Enter your character's name, or type new:


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Gsmith   (14 posts)  [Biography] bio
Date Reply #2 on Thu 24 Nov 2016 09:34 PM (UTC)
Message
Nick Gammon said:

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.
So, trigger matching has to be deferred to until a newline arrives.


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!
[Go to top] top

Posted by Fiendish   USA  (1,641 posts)  [Biography] bio   Global Moderator
Date Reply #3 on Fri 25 Nov 2016 09:42 AM (UTC)
Message
Nick Gammon said:

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.


Enter your character's name, or type new:


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.


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

https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Fri 25 Nov 2016 09:08 PM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Fiendish   USA  (1,641 posts)  [Biography] bio   Global Moderator
Date Reply #5 on Sun 27 Nov 2016 11:39 PM (UTC)

Amended on Sun 27 Nov 2016 11:52 PM (UTC) by Fiendish

Message
Nick Gammon said:

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.

https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Mon 28 Nov 2016 04:14 AM (UTC)
Message
If the data arrives quickly you shouldn't really see it twice because redrawing the screen is a comparatively low-priority event.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Gsmith   (14 posts)  [Biography] bio
Date Reply #7 on Mon 28 Nov 2016 03:49 PM (UTC)
Message
Nick Gammon said:

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!
[Go to top] top

Posted by Fiendish   USA  (1,641 posts)  [Biography] bio   Global Moderator
Date Reply #8 on Mon 28 Nov 2016 05:33 PM (UTC)
Message
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.

https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


2,366 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]