glfw 拖动窗口最初在 macOS 上是滞后的

Question

我刚刚使用 glfw 创建了一个窗口并在 macOS 上运行。问题是：如果我拖动窗口并四处移动，窗口的移动最初是超级滞后的，但后来变得平滑。Linux (Ubuntu) 上不会出现此问题。为什么以及如何解决它？系统：macOS 10.15.7 (19H2) 代码：package mainimport (    "fmt"    "runtime"    "github.com/go-gl/gl/v4.1-core/gl"    "github.com/go-gl/glfw/v3.3/glfw")func init() {    runtime.LockOSThread()}func main() {    err := glfw.Init()    if err != nil {        panic(fmt.Errorf("failed to initialize GLFW: %w", err))    }    defer glfw.Terminate()    glfw.WindowHint(glfw.Resizable, glfw.False)    glfw.WindowHint(glfw.ContextVersionMajor, 4)    glfw.WindowHint(glfw.ContextVersionMinor, 1)    glfw.WindowHint(glfw.OpenGLProfile, glfw.OpenGLCoreProfile)    glfw.WindowHint(glfw.OpenGLForwardCompatible, glfw.True)    win, err := glfw.CreateWindow(800, 600, "glfw", nil, nil)    if err != nil {        panic(err)    }    defer win.Destroy()    win.MakeContextCurrent()    if err := gl.Init(); err != nil {        panic(err)    }    win.SetTitle(fmt.Sprintf("%s", gl.GoStr(gl.GetString(gl.VERSION))))    gl.ClearColor(1.0, 1.0, 1.0, 1.0)    for !win.ShouldClose() {        gl.Clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)        win.SwapBuffers()        glfw.PollEvents()    }}

Answer 1

这个问题与 Go 无关。用 C 编写的示例也重现了该问题：

#include <GLFW/glfw3.h>

int main(void)

{

    GLFWwindow* window;

    /* Initialize the library */

    if (!glfwInit())

        return -1;

    /* Create a windowed mode window and its OpenGL context */

    window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);

    if (!window)

    {

        glfwTerminate();

        return -1;

    }

    /* Make the window's context current */

    glfwMakeContextCurrent(window);

    /* Loop until the user closes the window */

    while (!glfwWindowShouldClose(window))

    {

        /* Render here */

        glClear(GL_COLOR_BUFFER_BIT);

        /* Swap front and back buffers */

        glfwSwapBuffers(window);

        /* Poll for and process events */

        glfwPollEvents();

    }

    glfwTerminate();

    return 0;

}

简短的回答是：glfwWaitEvents在 macOS 上使用。

长答案是 glfwPollEvents 处理事件（如果有）。否则，它会立即返回。这意味着（微不足道的）程序正在尽可能快地一遍又一遍地清除屏幕，消耗大量的 CPU 时间。替代方案 glfwWaitEvents 在没有事件等待时阻塞，消耗很少或不消耗 CPU 时间。可以说，使用大量 CPU 的程序不应导致窗口滞后，但这实际上取决于操作系统及其分配资源的方式。

至于使用这两个函数中的哪一个，完全取决于我们还想让我们的程序做什么。如果我们只想对用户输入做出反应而没有别的，glfwWaitEvents 可能是要走的路。如果我们想在事件循环中做其他事情，glfwPollEvents 可能更合适，特别是如果我们想独立于用户输入重绘窗口内容。

另外：glfwSwapInterval(1) 也可能会避免延迟，因为它会导致 glfwSwapBuffers 阻塞几毫秒，再次让 CPU 休息。