Fix an issue where the telemetry app would "fall behind" Forza and become out of sync.

[tpressley]

Proposed solution to issue #42.

[tpressley]

Closing, further testing reveals that this doesn't entirely solve the issue (although it seems to lessen it)

[tpressley]

Actually going to re-open. I think it may be multiple issues (map rendering slowing things down as well?)

[tpressley]

Actually going to re-open. I think it may be multiple issues (map rendering slowing things down as well?)

I think this is it. Prior to the change in the PR, hitting "reset" would not cause the app to catch up to forza, however now when I hit reset it immediately returns to live data.

[austinbaccus]

Good investigation! I'm 99% sure that the slowness is because of the map drawing too many lines.

I've run into this issue before. The map eventually has to render so many lines that the rest of the UI slows down. The initial solution was to make the map 'snake' - where it starts deleting the oldest line every time a new line needs to be drawn after the map is X amount of lines long. The number was chosen based on the number of lines it took for the slowest car to lap the longest track in FM7, plus a bit of buffer. I also lowered the frequency that new data was sent to the map.

On my machine it worked well, but on other machines it might not be enough.

One solution is to simply lower the frequency or the max amount of lines that can be drawn before the snaking solution kicks in. Another is to make this configurable in an options menu. Another is to automatically detect the user's hardware and guess how many lines they can draw at once and set the number to that. But I think the best solution is render the map using the GPU.

I might temporarily reduce the number of lines in the snake until a performant GPU solution is implemented. I've never rendered a UI using the GPU in Electron (to be honest I'm not even sure that it's not using the GPU already), so this may take some time.

[austinbaccus]

@tpressley this is off-topic, but how does this app work with FH5? I'm waiting until the 9th to get it so I haven't been able to test it yet - I think you're the first!

[tpressley]

Good investigation! I'm 99% sure that the slowness is because of the map drawing too many lines.

I've run into this issue before. The map eventually has to render so many lines that the rest of the UI slows down. The initial solution was to make the map 'snake' - where it starts deleting the oldest line every time a new line needs to be drawn after the map is X amount of lines long. The number was chosen based on the number of lines it took for the slowest car to lap the longest track in FM7, plus a bit of buffer. I also lowered the frequency that new data was sent to the map.

On my machine it worked well, but on other machines it might not be enough.

One solution is to simply lower the frequency or the max amount of lines that can be drawn before the snaking solution kicks in. Another is to make this configurable in an options menu. Another is to automatically detect the user's hardware and guess how many lines they can draw at once and set the number to that. But I think the best solution is render the map using the GPU.

I might temporarily reduce the number of lines in the snake until a performant GPU solution is implemented. I've never rendered a UI using the GPU in Electron (to be honest I'm not even sure that it's not using the GPU already), so this may take some time.

I think it is a combination of issues. I tried to use UdpClient to get just RPM to display on a WPF app, and immediately started seeing the same latency that exists in your app. When I started disposing the listener before each call, the latency went away, which is why I'm suspecting some sort of buffering issue. AFAIK there is no way to clear out or even access any buffer that exists within the .NET 5.0 UdpClient class, other than disposal.

But it does seem that there are other things contributing to latency. Definitely the map, maybe even something else? I had one instance where clearing the map after making this change didn't cause the latency to immediately go away, but it was gone within about a minute or so.

@tpressley this is off-topic, but how does this app work with FH5? I'm waiting until the 9th to get it so I haven't been able to test it yet - I think you're the first!

It seems to work fine in FH5. Not noticing any differences from when I've used it in FH4.

[austinbaccus]

When does the latency start becoming apparent when using this app? Is it still immediate or does it take a few minutes? I've never noticed the C# side of things slowing down, but maybe I wasn't looking hard enough. I'll definitely be investigating this tonight.

[tpressley]

When does the latency start becoming apparent when using this app? Is it still immediate or does it take a few minutes? I've never noticed the C# side of things slowing down, but maybe I wasn't looking hard enough. I'll definitely be investigating this tonight.

Before the change I made, generally within a few minutes of playing I noticed latency. After it was fine most of the time, but it still had issues. I'm not 100% certain that my change fixes anything though, the more I play/test the more I see inconsistencies.

[austinbaccus]

@tpressley Here's what I noticed after trying to replicate this:

I noticed lag too

I played for 15 minutes on FH4 and hit the max amount of lines the map could draw. No lag. But I left the app and game running (paused) and went to watch an episode of Top Gear. When I came back there was definitely some lag.

I only noticed lag in the GUI, but not in the console output

The Electron app's `main.ts` code on line 69 outputs the steering angle value to a console window. I didn't notice any lag between my steering input and the value shown in the console window. There was definitely some lag in the Steering component in the GUI though.

So with that in mind, I think that the issue lays somewhere downstream of Electron's main.ts. For reference, here's the journey that a single data packet takes from start to finish:

Forza -> C# Program.cs -> Electron main.ts -> Electron Dashboard.tsx -> Electron Steering.js

But this hypothesis comes in direct conflict with your testing results. You noticed some improvements when you made changes to the C# code, which is upstream of main.ts. Maybe the code changes were unrelated or maybe there's something else going on here.

Restarting the game and the app had no effect on the amount of lag

After witnessing the lag I restarted both the a game and the app, but he lag was still there. I don't have enough expertise to have any guesses as to what this may indicate though.

[austinbaccus]

@tpressley I'm going to do some more testing. This is my first React/Electron project so I'm still figuring out how to use the Dev Tools. Hopefully I'll figure out a way to pinpoint the issue soon.

[austinbaccus]

There is one sub-process within the main process that is getting pretty large. This sub process started at 40MB and goes up by 9MB every second. However it goes down by 200MB every minute or so as well.

[austinbaccus]

I just played FH4 for ~2 hours straight and I couldn't get it to lag. Memory usage capped out at ~1000MB (which is something I need to cut down on in the future). Not sure why there's no lag this time unlike yesterday.

@tpressley maybe you ran out of RAM?

[pinheadtf2]

Hey, I'm very late to the party, but I found where this issue happens for me. I was playing Stories on FH5 last night, and it kept coming back, I'd notice it primarily around when it transitions to new vehicles and stuff but I'm not sure if that's a cause or me being slow. Either way, what I did then is click reset, then play the game as normal for a while until it caught up again. I'm gonna play it with this patch and rerun the same things to see if it happens or not. My computer specs are listed in my profile's carrd page if you need those.