Make the ship's log bigger

[csibbitt]

Originally submitted as a naïve constant tweak that caused UI performance problems, UI usability problems, and network performance problems.

With @oznogon 's help and some additional work in the engine, these are all fixed. This patch depends on:

• Sequenced vectors with efficient replication SeriousProton#239
• [GuiAdvancedScrollText] Performance improvements #2019
• [GuiScrollbar] Scrollbar limits fixed #2022
• [GuiAdvancedScrollText] Base scrollbar click change on text size #2021 (Recommended but not required)

[travishein]

👍

[oznogon]

Running with a client in the server (single EmptyEpsilon.exe instance), 8-core/16-thread Ryzen 9/RTX 3060, with a script that sent 100 entries upon scenario launch and one every 0.1 seconds after:

dock1 = PlayerSpaceship():setTemplate("Atlantis"):setPosition(-100, 0):setFaction("Human Navy")
i = 1
timeout = 0.1

for j = 1, 100, 1
do
    dock1:addToShipLog("Ack" .. i, "yellow")
    i = i + 1
end

function update(delta)
    timeout = timeout - delta
    if(timeout < 0)
    then
        dock1:addToShipLog("Ack" .. i, "yellow")
        i = i + 1
        timeout = 0.1
    end
end

By around 1,000 entries, the GuiSlider lozenge becomes too small to reliably use with touch:

By around 1,500 entries, the log begins to cause fps to dip below 60 on the Ship's Log screen.

By around 2,000 entries, the lozenge becomes too small to click.

By around 2,750 entries, the client is sending 500kb over the wire per second.

By around 3,000 entries, FPS drops to below 30fps.

At 3,500 entries, CPU fans start to spin up to handle the load and FPS drops to under 25.

At 4,000 entries, FPS is at 21 and the lozenge is nearly obscured by the scrollbar arrow.

At 4,500 entries we start flirting with 1MB over the wire per second.

Resource Monitor confirms this.

At this point I open up a client over the network on Relay.

With the Ship's Log minimized on Relay, we still get 140+ fps.

With it expanded, fps drops to 15.

I had to stop the server around 7,000 entries because my CPU was pinned and reporting 90C temps. FPS was around 12 and system performance outside of EE was beginning to be impacted.

• GuiSlider needs a minimum touch-friendly lozenge size
• Viewing the Ship's Log with large numbers of entries should not impact client or server fps
• At some point for network replication, log entries needs to be paginated, cacheable, or truncated for clients

[oznogon]

The ship log (the entire log, I think) is replicated to clients every frame. Not sure but I think this means it's replicated even to players who aren't using Relay/Ship's Log/any screen with access to the log?

EmptyEpsilon/src/spaceObjects/playerSpaceship.cpp

Line 581 in eb9ee8c

registerMemberReplication(&ships_log);

A dirty fix would reduce the replication frequency to 1.0 (1 second) or so. A better fix would send the entire log once to a new client and only send updates after that, but that would be a more dramatic implementation change.

[oznogon]

Tried sending 10000 entries to the player upon launch, instead of sending entries constantly, and I'm not seeing the replication. Still not great if each new entry replicates the entire log. Either way, FPS with the ship's log visible drops to <9 with 10,000 entries and stays there. The GuiScrollbar lozenge looks like it's 1px on load but doesn't appear to render if you scroll anywhere into the log.

@daid Does the log get replicated each frame or just on changes?

[oznogon]

daid via Discord:

yes, it's extremely inefficient, which is why it is so limited in size
it's not just that the whole log gets sent, it's also checking every entry for changes each tick.
... I'm planning to change this on with the ECS code

Re: GUI performance issues with >1,500 entries:

My guess, the minimized (view in Relay) just grabs the last line and displays that. But the expanded version first makes a "preparedfontrenderer" (call) for the all the lines, so it knows how much vertical space there is, and then draws a subsection of that.

[oznogon]

Found another GuiScrollbar limitation: after 400 entries, the bottom entries in the log can't be viewed by scrolling, and the granularity of scrolling via scrollbar arrows is 1px/click, or too little to be useful. #1940 (comment), #1941, #1942

[csibbitt]

@oznogon Thank you very much for testing this. I was expecting someone to explain the history of why it is like this, possibly with these sorts of details, but you did it with science! It seems we have at least a UI issue and a performance issue to deal with before this could become a reality. I'll check out the discord discussion and see what I can do to help.

[csibbitt]

Not sure if the CI system supports dependent changes, but this definitely won't even compile until daid/SeriousProton#239 merges, and is not very usable until the other two required changes merge.

[csibbitt]

With all of the changes in place, I was able to run the tests described here: daid/SeriousProton#239 (comment)