mrvn wrote: Mon Oct 25, 2021 11:29 pm
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.