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

Question

我刚刚使用 glfw 创建了一个窗口并在 macOS 上运行。问题是：如果我拖动窗口并四处移动，窗口的移动最初是超级滞后的，但后来变得平滑。Linux (Ubuntu) 上不会出现此问题。为什么以及如何解决它？

系统：macOS 10.15.7 (19H2) 代码：

package main

import (

    "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){&nbsp; &nbsp; GLFWwindow* window;&nbsp; &nbsp; /* Initialize the library */&nbsp; &nbsp; if (!glfwInit())&nbsp; &nbsp; &nbsp; &nbsp; return -1;&nbsp; &nbsp; /* Create a windowed mode window and its OpenGL context */&nbsp; &nbsp; window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);&nbsp; &nbsp; if (!window)&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; &nbsp; glfwTerminate();&nbsp; &nbsp; &nbsp; &nbsp; return -1;&nbsp; &nbsp; }&nbsp; &nbsp; /* Make the window's context current */&nbsp; &nbsp; glfwMakeContextCurrent(window);&nbsp; &nbsp; /* Loop until the user closes the window */&nbsp; &nbsp; while (!glfwWindowShouldClose(window))&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; &nbsp; /* Render here */&nbsp; &nbsp; &nbsp; &nbsp; glClear(GL_COLOR_BUFFER_BIT);&nbsp; &nbsp; &nbsp; &nbsp; /* Swap front and back buffers */&nbsp; &nbsp; &nbsp; &nbsp; glfwSwapBuffers(window);&nbsp; &nbsp; &nbsp; &nbsp; /* Poll for and process events */&nbsp; &nbsp; &nbsp; &nbsp; glfwPollEvents();&nbsp; &nbsp; }&nbsp; &nbsp; glfwTerminate();&nbsp; &nbsp; return 0;}简短的回答是：glfwWaitEvents在 macOS 上使用。长答案是 glfwPollEvents 处理事件（如果有）。否则，它会立即返回。这意味着（微不足道的）程序正在尽可能快地一遍又一遍地清除屏幕，消耗大量的 CPU 时间。替代方案 glfwWaitEvents 在没有事件等待时阻塞，消耗很少或不消耗 CPU 时间。可以说，使用大量 CPU 的程序不应导致窗口滞后，但这实际上取决于操作系统及其分配资源的方式。至于使用这两个函数中的哪一个，完全取决于我们还想让我们的程序做什么。如果我们只想对用户输入做出反应而没有别的，glfwWaitEvents 可能是要走的路。如果我们想在事件循环中做其他事情，glfwPollEvents 可能更合适，特别是如果我们想独立于用户输入重绘窗口内容。另外：glfwSwapInterval(1) 也可能会避免延迟，因为它会导致 glfwSwapBuffers 阻塞几毫秒，再次让 CPU 休息。