GLFW delays first event after some idle time


#1

I am observing a strange behavior of a dead simple program. I am using Go bindings. MacOS 10.13.3

package main

import (
    "fmt"

    "github.com/go-gl/gl/v2.1/gl"
    "github.com/go-gl/glfw/v3.1/glfw"
)

func main() {
    if err := gl.Init(); err != nil {
        panic(err)
    }
    if err := glfw.Init(); err != nil {
        panic(err)
    }
    window, err := glfw.CreateWindow(800, 600, "Window", nil, nil)
    if err != nil {
        panic(err)
    }
    window.SetCharCallback(func(w *glfw.Window, char rune) {
        fmt.Println(string(char))
    })
    for !window.ShouldClose() {
        glfw.WaitEvents()
    }

}

When I run the program, a window appears. I press keyboard keys and see output in terminal window, as expected. But when I press a key after not touching anything for few minutes, corresponding output appears in terminal only after few seconds after pressing the key. Using PollEvents() instead of WaitForEvents() does not change anything


#2

I’ve not observed this behaviour with GLFW using C code, such as the GLFW events.c test.

This might be due to the bindings, but if you’re able to test events.c (compiled from GLFW master source) on your machine this might reveal if there is an issue with GLFW and your system setup.


#3

I tried the C program, and there are no delays. So, possibly the problem may be in Go bindings.

Anyway, I solved the issue this way:

package main

import (
    "fmt"
    "time"

    "github.com/go-gl/gl/v2.1/gl"
    "github.com/go-gl/glfw/v3.1/glfw"
)

func main() {
    if err := gl.Init(); err != nil {
        panic(err)
    }
    if err := glfw.Init(); err != nil {
        panic(err)
    }
    window, err := glfw.CreateWindow(800, 600, "Window", nil, nil)
    if err != nil {
        panic(err)
    }
    window.SetCharCallback(func(w *glfw.Window, char rune) {
        fmt.Println(string(char))
    })
    go func() {
        for {
            <-time.After(time.Second)
            glfw.PostEmptyEvent()
        }
    }()
    for !window.ShouldClose() {
        glfw.WaitEvents()
    }

}

Basically, I post an empty event periodically, and that prevents the delay even if the program is idle for a long time


#4

Finally I got it

The problem is with output to terminal, not GLFW. After some idle time, output appears in terminal with a delay after a call to fmt.Println(). I added timestamps to strings printed, and they show that callbacks are fired immediately after an event, but they appear in terminal later.

So no GLFW issue here


#5

Excellent, glad to see you’ve found the issue (and that it isn’t GLFW).