diff options
author | wm4 <wm4@nowhere> | 2014-04-08 19:02:57 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2014-04-17 22:58:47 +0200 |
commit | 8f5eb7b780cf7598157179d0679863e3b7a90084 (patch) | |
tree | 0e9600dc21cda406172f22c3664f5515b0555d29 /VERSION | |
parent | b991c072f69e2fa4b842060ed5a7a8b1ece09f52 (diff) | |
download | mpv-8f5eb7b780cf7598157179d0679863e3b7a90084.tar.bz2 mpv-8f5eb7b780cf7598157179d0679863e3b7a90084.tar.xz |
vo_vdpau: simplify previous vsync timestamp calculation
The strange thing about this code was the shift parameter of the
prev_vs2 function. The parameter is used to handle timestamps before the
last vsync, since the % operator handles negative values incorrectly.
Most callers set shift to 0, and _usually_ pass a timestamp after the
last vsync. One caller sets it to 16, and can pass a timestamp before
the last timestamp.
The mystery is why prev_vs2 doesn't just compensate for the % operator
semantics in the most simple way: if the result of the operator is
negative, add the divisor to it. Instead, it adds a huge value to it
(how huge is influenced by shift). If shift is 0, the result of the
function will not be aligned to vsyncs.
I have no idea why it was written in this way. Were there concerns about
certain numeric overflows that could happen in the calculations? But I
can't think of any (the difference between ts and vc->recent_vsync_time
is usually not that huge). Or is there something more clever about it,
which is important for the timing code? I can't think of anything
either.
So scrap it and simplify it.
Diffstat (limited to 'VERSION')
0 files changed, 0 insertions, 0 deletions