3

I'm using glium as my opengl bindings, but it's impossible to get a reliable 60 FPS.

A minimal testcase is

#[macro_use]
extern crate glium;
extern crate clock_ticks;

use glium::Surface;
use glium::glutin;

fn main() {
    use glium::DisplayBuild;

    let display = glutin::WindowBuilder::new()
        .build_glium()
        .unwrap();

    let frames = 60 * 5;
    let trials = 3;

    for _ in 0.. trials {
        let start_ns = clock_ticks::precise_time_ns();
        for _ in 0..frames {
            display.draw().finish().unwrap();
        }

        let duration_ns = clock_ticks::precise_time_ns() - start_ns;
        let duration_s = (duration_ns as f64) / 1_000_000_000f64;
        let fps = (frames as f64) / duration_s;
        let dropped = (duration_s - (frames as f64 * (1f64/60f64))) / (1f64/60f64);

        println!("{} frames in {:.6} seconds = {:.3} fps (estimated {:.1} frames dropped)", frames, duration_s, fps, dropped);
    }
}

Where I would expect 60 FPS, but is frequently showing 59 FPS when I'm running it (in OSX). The project is available on github for ease of compiling and running.

Is there any way I can tweak glium so that it won't drop frames? OSX is overriding the vsync setting, so there's no way not to wait for vsync between each frame.

Johannes Hoff
  • 3,731
  • 5
  • 31
  • 37
  • I see at least two potential sources of inaccuracy with your measurements: 1) Floating point. 2) Process switching. I would suggest measuring individual frame times rather than averaging a huge number of them together. If you're actually having a problem with vsync, it should become obvious when you've got wildly varying frame times. If not, then you've just saved yourself a lot of frustration trying to solve a problem that didn't exist. – 8bittree Sep 28 '15 at 00:19
  • I forked the project and added a bit of code to print out frame times, then submitted it as a [pull request here](https://github.com/johshoff/minimal_glium/pulls). The machine I tested it on, Ubuntu with an Intel HD 5500 was reported FPS of slightly over 60 typically. Frame times were right around 16.6ms +- ~0.5ms – 8bittree Sep 29 '15 at 02:16
  • I didn't put any per-frame info into the main loop just to make it extremely clear that nothing else is going on. Thanks for the contribution, though. Unfortunately, your debugging info adds too much delay (my terminal, iterm2, is too slow?) to get any valuable information. – Johannes Hoff Sep 29 '15 at 03:51
  • Hmm, interesting. Try it in terminal.app and/or redirecting to a file. – 8bittree Sep 29 '15 at 03:55
  • Piping to a file works better. It uncovers at least two intersting things: 1. The average frame time is more like 16.80ms than 16.67ms, throwing my estimated frame drops off a little. 2. It clearly shows some frames at close to 32ms, which seems like I missed a vsync. I also added a column for watching the drift from 60Hz. Raw output: https://gist.github.com/johshoff/645d138100ab8fd69904 – Johannes Hoff Sep 30 '15 at 05:41

1 Answers1

1

Yes, like @8bitree, I suspected that you are measuring incorrectly, rather than it being an actual problem. On my system, Debian:

steve@warmachine:~/tmp/guess$ cargo run
     Running `target/debug/guess`
300 frames in 4.427656 seconds = 67.756 fps (estimated -34.3 frames dropped)
300 frames in 0.006892 seconds = 43529.834 fps (estimated -299.6 frames dropped)
300 frames in 0.006522 seconds = 45997.412 fps (estimated -299.6 frames dropped)
steve@warmachine:~/tmp/guess$ cargo run
     Running `target/debug/guess`
300 frames in 4.953447 seconds = 60.564 fps (estimated -2.8 frames dropped)
300 frames in 4.999410 seconds = 60.007 fps (estimated -0.0 frames dropped)
300 frames in 1.608712 seconds = 186.485 fps (estimated -203.5 frames dropped)

So yeah, something is a bit... odd.

Steve Klabnik
  • 14,521
  • 4
  • 58
  • 99
  • That is quite some variance. It kind of looks like you're switching between vsynced and not vsynced. I'd be interested in seeing what your frame times are. – 8bittree Sep 29 '15 at 02:18
  • I see this same behavior of thousands of frames per second if the main window loses focus. Is that the case? – Johannes Hoff Sep 29 '15 at 03:43
  • @JohannesHoff I use XMonad, so, maybe? – Steve Klabnik Sep 29 '15 at 03:43
  • And yes, it is an actual problem that I observed in a game I was building. Stripping it down to the bare minimum I got the test case included. It certainly is an uninteresting program, but if that one can't give me 60 fps I certainly can't get that with anything more complicated. – Johannes Hoff Sep 29 '15 at 03:45