Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ Mushclient renders text to screen twice for trigger re-colouring?
|
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 page
| Posted by
| Gsmith
(14 posts) 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? | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) 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 | | Top |
|
| Posted by
| Gsmith
(14 posts) 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! | | Top |
|
| Posted by
| Fiendish
USA (2,534 posts) 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) 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 | | Top |
|
| Posted by
| Fiendish
USA (2,534 posts) 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) 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 | | Top |
|
| Posted by
| Gsmith
(14 posts) 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! | | Top |
|
| Posted by
| Fiendish
USA (2,534 posts) 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 | | 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.
22,957 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top