ANSI color performance

Posted by Mudaddict on Fri 31 Mar 2023 06:38 AM — 21 posts, 50,825 views.

Mudaddict Fri 31 Mar 2023 06:38 AM #0

I was wondering if anyone has any ideas on how to improve the ansi color rendering performance. It appears that if there is lots of ansi color text being displayed, the framerate of the renderer is significantly slower. So much so that on a fast pace mud fight that has over 100 lines of text, the renderer is so slow that the text of the next round would have already started before you can see the end of the first round.
This is in comparison to no ansi color and the text renders fast and perfectly fine.
This is definitely a render slowness issue because the mud triggers get sent in time and before the text is even rendered. So its not a network traffic issue.
I was looking at the code, and I think the ExtTextOut function is either slow for this purpose, or with ansi coloring, gets called many times. I did not debug this yet.
I did some research and found references to Direct2D drawing being slow, https://devblogs.microsoft.com/commandline/case-study-how-many-colors-are-too-many-colors-for-windows-terminal/
Not sure if that brings any insight.

Fiendish USA Global Moderator Fri 31 Mar 2023 05:49 PM #1

Can confirm. This makes my client bog all the way down when the output is in view:


require "aardwolf_colors" -- https://raw.githubusercontent.com/fiendish/aardwolfclientpackage/MUSHclient/MUSHclient/worlds/plugins/aardwolf_colors.lua

ansi_string = ColoursToANSI(string.rep("@x026/@x227/@x195/@x191/@x085/", 30))
for i=1,100 do Simulate(ansi_string.."\r\n") end

Nick Gammon Australia Forum Administrator Fri 31 Mar 2023 10:44 PM #2

Also:


https://raw.githubusercontent.com/fiendish/aardwolfclientpackage/MUSHclient/MUSHclient/lua/string_split.lua

Nick Gammon Australia Forum Administrator Fri 31 Mar 2023 10:52 PM #3

I can't reproduce that. Using Fiendish's test code the client seems responsive both under Windows XP and under Ubuntu 22.04 using Wine.

Quote:

This makes my client bog all the way down when the output is in view:

You need to define that numerically. As far as I could see I could scroll up/down, and page up/down without any issues. Perhaps it is the font you are using? What font and what font size are you using for the test? I was using Fira Code.

Nick Gammon Australia Forum Administrator Fri 31 Mar 2023 10:53 PM #4

Mudaddict said:

I was wondering if anyone has any ideas on how to improve the ansi color rendering performance.

Please help us by advising the version of MUSHclient you are using. Use the Help menu -> About MUSHclient.

Also what operating system are you using?

Mudaddict Sat 01 Apr 2023 06:35 AM #5

Version is 5.06. Running on windows 11, but have used it since Windows 7 and the ansi performance has not changed.

Mudaddict Sat 01 Apr 2023 06:36 AM #6

Nick Gammon said:

I can't reproduce that. Using Fiendish's test code the client seems responsive both under Windows XP and under Ubuntu 22.04 using Wine.

Quote:

This makes my client bog all the way down when the output is in view:

Font is the default. I have not changed font settings. That is to say, it uses FixedSys 9pt.
To be clear, the client is perfectly responsive to input and triggers etc. What is slow is the mud text being output into the client. The text is just slow to render out into the window as compared to no ansi text.
I tried changing the font and it made no difference.

Also in case anyone was wondering if my PC is some slow POS from the 90s, no, its quite modern, intel 12th gen cpu, 32 GB ram.

Nick Gammon Australia Forum Administrator Sat 01 Apr 2023 07:22 AM #7

Can you please make an (unlisted) YouTube video showing what you are talking about? Maybe what you think is slow, I think is fast. Or maybe there is something else going on here.

Mudaddict Sat 01 Apr 2023 07:42 AM #8

Nick Gammon said:

Can you please make an (unlisted) YouTube video showing what you are talking about? Maybe what you think is slow, I think is fast. Or maybe there is something else going on here.

Here we go
https://youtu.be/GXRyY87dasU

This sample is not as bad as some fight samples. Notice that in the ansi version, the text scroll has a few hiccups while the non ansi text has only one hiccup. Its not the greatest example admittedly.

ALso it is not the network or packets. As mentioned previously, the triggers are run before i see the text that would cause the trigger. How do I know? Because I multiplay and I see the result of the trigger on the other windows (without ansi) before I see my trigger text on the ansi window.

Here is the fight scene with multiplay, notice the ansi foreground window is way slower than the background non ansi windows

https://youtu.be/XbV9aNmuIq8

Nick Gammon Australia Forum Administrator Sat 01 Apr 2023 09:47 AM #9

When I was playing World of Warcraft with three simultaneous windows (three connections, three clients) it tended to slow down a lot.

I'm rather impressed that you can run 19 connections in MUSHclient and still get reasonable performance.

The nature of the rendering pipeline is that it has to call ExtTextOut for each style run (ie. colour change). No doubt ExtTextOut is more efficient when processing 80 characters in one call rather than one character, because you therefore are calling it 80 times as often (even if it has to do more per call).

Still, I'll look into it.

Mudaddict Sat 01 Apr 2023 03:26 PM #10

Nick Gammon said:

When I was playing World of Warcraft with three simultaneous windows (three connections, three clients) it tended to slow down a lot.

I'm rather impressed that you can run 19 connections in MUSHclient and still get reasonable performance.

The nature of the rendering pipeline is that it has to call ExtTextOut for each style run (ie. colour change). No doubt ExtTextOut is more efficient when processing 80 characters in one call rather than one character, because you therefore are calling it 80 times as often (even if it has to do more per call).

Still, I'll look into it.

Appreciate this. Will remove the YT videos.

Fiendish USA Global Moderator Sun 02 Apr 2023 05:01 AM #11

It appears to depend for me on whether the mouse cursor is hovering near the left of the output or the right (or somewhere in between). Hovering the mouse over the leftmost column shows no slowdown at all when scrolling. Moving the mouse over to the rightmost column shows significant slowdown when scrolling. I bet it's a similar issue to https://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=13688

See video capture here: https://i.imgur.com/aigMwuo.mp4
In the video my cursor starts on the left and I scroll up and down. With the cursor on the left side the scrolling performance is fine. Then I move it over to the right and scroll up and down again, and the performance tanks. Then I move the cursor back to the left side and the scroll performance is fine again.

This is with a completely stock MUSHclient 5.06 install with the exe replaced with the latest from github.
OS in my case is always weird. Wine 7.7 (crossover 22.0.1) on macOS 12.6.4.

Nick Gammon Australia Forum Administrator Mon 03 Apr 2023 10:27 AM #12

Interesting. Well, @Mudaddict, see if the same applies to you. Does it work better with the mouse to the left of the window?

Mudaddict Tue 04 Apr 2023 12:02 AM #13

Nick Gammon said:

Interesting. Well, @Mudaddict, see if the same applies to you. Does it work better with the mouse to the left of the window?

It made no difference where the cursor was, the performance was the same, slow.

Nick Gammon Australia Forum Administrator Wed 05 Apr 2023 09:28 PM #14

OK, here is my test:



https://www.youtube.com/watch?v=B2LDAASHlYY

I put a sequence number on the left (test number). As you can see it refreshes so quickly the sequence number for the entire batch of lines just jumps from one to the other. There is no visible scrolling.

This is running version 5.06 under Windows XP.

Exact test code:


require "aardwolf_colors" -- https://raw.githubusercontent.com/fiendish/aardwolfclientpackage/MUSHclient/MUSHclient/worlds/plugins/aardwolf_colors.lua

sequence = (sequence or 0) + 1
print (string.rep ("-", 60))
ansi_string = ColoursToANSI(string.rep("@x026/@x227/@x195/@x191/@x085/", 30))
for i=1,100 do Simulate("Seq " .. sequence .. ": " .. i .. " " .. ansi_string.."\r\n") end
print (string.rep ("-", 60))

print ("Sequence", sequence)

The cursor is on the right because it is clicking the Run button. For the last couple of tests I moved the cursor over the text and hit Enter to run the test.

Mudaddict Thu 06 Apr 2023 03:24 AM #15

Nick Gammon said:

OK, here is my test:



https://www.youtube.com/watch?v=B2LDAASHlYY


require "aardwolf_colors" -- https://raw.githubusercontent.com/fiendish/aardwolfclientpackage/MUSHclient/MUSHclient/worlds/plugins/aardwolf_colors.lua

sequence = (sequence or 0) + 1
print (string.rep ("-", 60))
ansi_string = ColoursToANSI(string.rep("@x026/@x227/@x195/@x191/@x085/", 30))
for i=1,100 do Simulate("Seq " .. sequence .. ": " .. i .. " " .. ansi_string.."\r\n") end
print (string.rep ("-", 60))

print ("Sequence", sequence)

The cursor is on the right because it is clicking the Run button. For the last couple of tests I moved the cursor over the text and hit Enter to run the test.

So running these scripts, the rendering is fast. Now I'm wondering if something else is the cause. Wondering if it is indeed network related?

Nick Gammon Australia Forum Administrator Thu 06 Apr 2023 10:37 AM #16

Well ... Fiendish reported that the script slowed his rendering down. What about you?

Fiendish USA Global Moderator Thu 06 Apr 2023 11:53 AM #17

We may be testing different things. My slowdown happens when scrolling the output after the text has been written. Something is happening there that does not happen when the text is being written in the first place.

Nick Gammon Australia Forum Administrator Thu 06 Apr 2023 09:07 PM #18

I see. Well, here is another test, using the same screen content as the earlier video, but now with me scrolling back and forwards using page-up/page-down and then the mousewheel. The mouse cursor is positioned to the right-hand side of the text.



https://www.youtube.com/watch?v=bLGXJMnWFqA

Nick Gammon Australia Forum Administrator Thu 06 Apr 2023 09:54 PM #19

You've taken your videos down which is unfortunate as we are still debugging this.

I am wondering if the redraw is slow if you scroll back and forwards (like Fiendish did) or if it is just slow as the text is delivered.

If it is slow in real-time (ie. during a fight) and not when you scroll back and forwards, then perhaps you have a plugin that is analysing the incoming data, and if there are lots of colour changes (and hence lots of style runs) then that is slowing down the plugin.

Mudaddict Fri 07 Apr 2023 02:01 AM #20

Nick Gammon said:

You've taken your videos down which is unfortunate as we are still debugging this.

I am wondering if the redraw is slow if you scroll back and forwards (like Fiendish did) or if it is just slow as the text is delivered.

If it is slow in real-time (ie. during a fight) and not when you scroll back and forwards, then perhaps you have a plugin that is analysing the incoming data, and if there are lots of colour changes (and hence lots of style runs) then that is slowing down the plugin.

It is slow during a fight, not scrolling. I tried scrolling both the mud text and the script text (with 1000 lines) and no issue at all, page up page down, mouse wheel, drag scrollbar, cursor on left, cursor on right, no issues.
I have no plugins, i have a default installation. I have scripts and triggers and timers, but the slowness happens even without them.

But now I'm wondering if its the mud im on. I tried aardwolf mud and it was fast listing "who".

The mud that is slow that im on is www.lofe.org port 8000.