Make production graphs cleaner

[mrvn]

And what is up with the fluid graphs in factorio? I made a test with one heat exchanger being fed by infinity pipe and a pump filling a fluid wagon. Stepping through it tick by tick when a train arrives or leaves shows me the pump and heat exchanger go full flow in a tick and shut down just as fast. Yet the production window shows a ~20 ticks ramp up and down of steam production.

Is it not recording enough data and interpolating the values in the 5s graph?

[UkcsAlias]

You aren't. You don't add up all the data points that go into each pixel. Instead it's a sliding window. As the graph advances the data point from "T-N" is subtracted and the data point for "T" is added. All the data points in between are carried over.

Even for keyframes, it has to look back to some of its old data to decide the actual keyframe information. For a 5s graph it might just use each frame independantly per pixel of width. For a 60s graph, it has to put 12 frames in each pixel. Its best to have that value calculated, rather than using just that value of that frame (if that would be done, the graph would become very bouncy and unreadable).

So thats why you decide certain keyframes. And they are based on graph durations.

Lets for simplicity only consider the following graph durations: 5s, 20s, 60s.
For each graph, you will need 300 keyframes to get a proper render. The 5s graph on that is just taking every frame.
The 20s graph, can take 4 frames and merge them to 1, which is placed in the keyframe. This means it has to perform 4 lookups worth of data to generate this information (which shouldnt be too much overhead).
The 60s graph, instead of again taking information from the 5s graph, can just directly relate to the 20s graph, and take 3 frames from that. Reducing overhead a lot.

Which calculation is used doesnt even matter a lot, as min, max and average will all give very accurate values because even though the 60s graph only takes 3 frames instead of 60, those 3 frames were all still based on the 20 frames and equaly balanced.

But it is load, and especialy on heavy saves. It does take up data into ram (note that graphs can scale verticaly, so taking an image doesnt work). And this load should be rather simple. But again, even small things can add up and influence FPS. A 0.1% additional load might not sound like a lot. But it still means that each 1000th frame you already lose 1. And that lost frame essentialy happens every 16.6 seconds.
This is why i think its a doable part. But my 0.1% might also be too optimistic. Because remember, there is a lot of data it has to look up in older frames (its not just a single number, its a lot of numbers together).

EDIT: but to note that to get keyframes, it only has to calculate this at certain frames, its not N*2 per frame, as only the 4th frame it decides the 20s frame, and each 12th frame the 60s frame. Its not even going to get close to double the costs, unless the base cost is significantly higher to counter the optimizations of the keyframes.

[mrvn]

You aren't. You don't add up all the data points that go into each pixel. Instead it's a sliding window. As the graph advances the data point from "T-N" is subtracted and the data point for "T" is added. All the data points in between are carried over.

Even for keyframes, it has to look back to some of its old data to decide the actual keyframe information. For a 5s graph it might just use each frame independantly per pixel of width. For a 60s graph, it has to put 12 frames in each pixel. Its best to have that value calculated, rather than using just that value of that frame (if that would be done, the graph would become very bouncy and unreadable).

So thats why you decide certain keyframes. And they are based on graph durations.

Lets for simplicity only consider the following graph durations: 5s, 20s, 60s.
For each graph, you will need 300 keyframes to get a proper render. The 5s graph on that is just taking every frame.
The 20s graph, can take 4 frames and merge them to 1, which is placed in the keyframe. This means it has to perform 4 lookups worth of data to generate this information (which shouldnt be too much overhead).
The 60s graph, instead of again taking information from the 5s graph, can just directly relate to the 20s graph, and take 3 frames from that. Reducing overhead a lot.

Which calculation is used doesnt even matter a lot, as min, max and average will all give very accurate values because even though the 60s graph only takes 3 frames instead of 60, those 3 frames were all still based on the 20 frames and equaly balanced.

But it is load, and especialy on heavy saves. It does take up data into ram (note that graphs can scale verticaly, so taking an image doesnt work). And this load should be rather simple. But again, even small things can add up and influence FPS. A 0.1% additional load might not sound like a lot. But it still means that each 1000th frame you already lose 1. And that lost frame essentialy happens every 16.6 seconds.
This is why i think its a doable part. But my 0.1% might also be too optimistic. Because remember, there is a lot of data it has to look up in older frames (its not just a single number, its a lot of numbers together).

EDIT: but to note that to get keyframes, it only has to calculate this at certain frames, its not N*2 per frame, as only the 4th frame it decides the 20s frame, and each 12th frame the 60s frame. Its not even going to get close to double the costs, unless the base cost is significantly higher to counter the optimizations of the keyframes.

Which has nothing to do with this suggestion and factorio already must do something like this for it's graphs for sure. I seriously don't believe the 10h graph works with data from every tick for the last 10 hours. That would mean the graphs data store would continously grow and displaying them would be horrible slow.

The suggestion only concerns the rendering and would build the average of N key frames for each pixel. And each pixel can be computed from the previous with one addition, one subtraction and one division. And as you scroll you only need to compute one new pixel per item. So this is miniscule work. 0.00000001% region.

Oh in case it isn't clear: This extra addition, subtraction and division as well as storing the last pixels non-divided value per item in the graph is only when the graph window is open. There is 0 change for the data collection that goes on all the time.

[Koub]

[Koub] Merged several threads with the same suggestion.