Michel Dänzer <mic...@daenzer.net> writes: >> actual_period = n * r - ε > > Is that still an issue if the (minimal) length of a vertical blanking > period is subtracted from the computed period?
What you're doing is defining a 'window' of times which match the desired frame -- any time within 'length of vertical blanking period' of the actual top of frame matches that frame. I'm simply making that window as large as possible by using 'half the frame time' instead of 'length of vertical blanking period'. > FWIW, one thing making "not before" semantics attractive is that > they're easy to achieve in the kernel: It can just make sure the page > flip isn't programmed to hardware before the target time. Yup, offering only 'not before' makes it easy to implement in the kernel, but very difficult for the application to get the right result. For fixed refresh rate monitors, converting from 'nearest to time T' to 'not before frame count F' conversion can be done by rounding T/rate to F and then using that to program the hardware using 'not before' semantics. For variable refresh rate monitors, the computation will be slightly more complicated as it may involve some multiple of a nominal frame rate plus some stretching of the final frame. > PresentOptionUST has never been functional, so there can't be any > clients relying on specific semantics (other than being a no-op :) for > it. Therefore, we could still change its semantics before making it > functional, FWIW. Oops. Someone should fix that :-) -- -keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
