I suspect the information should not be too hard to extractThe refresh rate of monitor(s) is not hard to extract, but the graphics driver v-sync settings... I don't think you can.
The refresh rate of monitor(s) is not hard to extract
One solution is to measure the duration between two consecutive (empty) frames when the application starts.
... but without knowing exactly what you do, it's hard to say more.
This is precisely what I want. I'm not sure if one can query the refresh rate of the monitor itself, but I'd like to get the rate at which the system is sending frames out to it.The refresh rate of monitor could easily be added to sf::VideoMode; I think all back-ends already have this information, it's just a matter of exposing it in the public API.
The refresh rate of monitor could easily be added to sf::VideoMode; I think all back-ends already have this information, it's just a matter of exposing it in the public API.Plase do!
But I don't think it is relevant.I beg to differ: It would be a good starting point. Currently I am using some default which seems sensible, assuming 50fps. If I had information from the system, I could use that as the starting point and with a bit of luck this starting point is better than guessing a 'plausible' value.
I beg to differ: It would be a good starting point.Have you read what I said about the GPU driver?
I did read that. Be assured, I'm glad that you take the time to give good advice and I carefully read everything you write. Let me explain in more detail what my problem is:QuoteI beg to differ: It would be a good starting point.Have you read what I said about the GPU driver?
I don't think you understand what I'm trying to explain...But I do! I want precisely the time between two GPU frames. I don't think the graphics driver can even know what the monitor does, and I am not concerned with this datum. I thought the time between two GPU frames is what you set when setting the FPS in the system settings, but I may have misunderstood that bit. I thought the graphics hardware simply produces a signal which the monitor adapts to - or stays black if it can't handle the signal.
So is it possible to query the time between two GPU frames?I don't think so. This is specific to the graphics driver (this is not handled by the OS), and there's no API to play with the graphics driver settings.
- take the time delta between successive calls to display()Timing a frame is fairly accurate but not great so adding those frame times would cumulate their error.
- if the animated sequence has run for at least 25 frames, cumulate the delta
- calculate the time between GPU frames as the average of the cumulated deltas
Timing a frame is fairly accurate but not great so adding those frame times would cumulate their error.The error does not cumulate because the times I measure actually vary around a fixed value, the GPU frame time (at least I think that is constant!). After many observations, the variations cancel out and the underlying period manifests in the mean. What I'm timing is the time from one call to display to the next; there is nothing to get 'in between'.
It would be more accurate - if you need it - to just measure the time after 25 frames have passed and then divide for the average.
I believe that what Hapax meant by error accumulation is the error (inaccuracy) caused by std::chrono, which does accumulate when using multiple measurements.It does not, in this case. Let me explain. What we are looking at is a sequence of time points:
tk = k * dt + ekThis formula rather matches a single measurement for the whole k-frames duration, but you said you were cumulating single frame times, which would rather be expressed as:
Sorry to go on about this, but I did say that I am cumulating the deltas *inside an animated sequence*. My software switches between showing still images and animated sequences, which happens when the user zooms, pans, etc.. So my measurement does indeed look at an average over several k-frame durations. I have a frame counter counter which is reset to zero whenever the system is at rest. When I get to the call to display I look at this counter, and if it's greater than zero, I know the previous frame was already inside the animation sequence and I cumulate the delta. Cumulating single deltas has the advantage that the average is right at hand at every moment, rather than having to bother with recording sequence starting times and counting frames per sequence.Quotetk = k * dt + ekThis formula rather matches a single measurement for the whole k-frames duration, but you said you were cumulating single frame times, which would rather be expressed as:tk = sum(dt + ek)