在Windows 10上无法绘制Golang OpenGL线，但Linux可以

在Windows 10上使用Golang OpenGL绘制线条时，仅绘制了第二条线，而在Linux上却能正确绘制两条线。调查发现，在每次绘制一条线后调用window.SwapBuffers()是导致差异的原因。在现代系统上，缓冲区交换会显示帧缓冲区内容并提供一个新的离屏缓冲区用于绘制，而OpenGL会调用glClear清除该缓冲区。在Linux上，帧缓冲区内容似乎被保留，但在Windows 10上，新的帧缓冲区被清除，导致仅显示第二条线。

我使用用 golang 编写的相同 opengl 代码在 640x480 像素空间中绘制两条线。我很困惑，因为在 linux 中两条线都正确绘制，但在 windows10 中只绘制了其中一条。是什么导致了 opengl 行为的差异？

• 第 1 行：0,0 - 639,479（仅适用于 linux）
• 第 2 行：50,0 - 0,50（适用于 linux 和 windows10）

在 linux 上，两条线都正确绘制：

来自 linux 的应用程序日志：

2019/08/15 02:44:12 requesting window for opengl 3.3
2019/08/15 02:44:12 graphicsstart(9): 640 x 480
2019/08/15 02:44:12 opengl version 3.3 (core profile) mesa 18.2.8
2019/08/15 02:44:12 opengl program: 3
2019/08/15 02:44:12 pixeltoclip: 0 x 0 => -1.000000 x 1.000000
2019/08/15 02:44:12 pixeltoclip: 639 x 479 => 1.000000 x -1.000000
2019/08/15 02:44:12 pixeltoclip: 50 x 0 => -0.843506 x 1.000000
2019/08/15 02:44:12 pixeltoclip: 0 x 50 => -1.000000 x 0.791232

在windows10上，只绘制第二条线：

来自 windows10 的应用程序日志：

2019/08/15 18:41:19 requesting window for opengl 3.3
2019/08/15 18:41:19 graphicsstart(9): 640 x 480
2019/08/15 18:41:19 opengl version 3.3.0 - build 21.20.16.4627
2019/08/15 18:41:19 opengl program: 3
2019/08/15 18:41:19 pixeltoclip: 0 x 0 => -1.000000 x 1.000000
2019/08/15 18:41:19 pixeltoclip: 639 x 479 => 1.000000 x -1.000000
2019/08/15 18:41:19 pixeltoclip: 50 x 0 => -0.843506 x 1.000000
2019/08/15 18:41:19 pixeltoclip: 0 x 50 => -1.000000 x 0.791232

这是该应用程序的完整源代码：

$ cat a.go
// # recipe for running a.go (Go 1.11 or higher)
// mkdir tmp                                    ;# create dir for module
// cp a.go tmp                                  ;# put app in dir
// cd tmp                                       ;# enter dir
// go mod init tmp                              ;# init module
// go get -u github.com/udhos/basgo@mainthread  ;# get lib from branch mainthread
// go run a.go                                  ;# run

package main

import (
        "github.com/faiface/mainthread"
        "github.com/udhos/basgo/baslib"
)

func main() {
        mainthread.Run(run)
}

func run() {
        mainthread.Call(func() {
                baslib.G = baslib.InitWin(640, 480)
        })
        baslib.Cls()
        baslib.Screen(9)
        baslib.Color(7, 5)
        baslib.Line(0, 0, 639, 479, -1, -1) // Line 1 (only linux)
        baslib.Line(50, 0, 0, 50, -1, -1)   // Line 2 (linux + windows)
        baslib.Print(baslib.InputCount(1))  // wait keyboard
        baslib.Println(``)
        baslib.Cls()
        baslib.Color(2, -1)
        for i := 50; i <= 300; i++ {
                baslib.Line(100, 50, 319, i, -1, -1)
        }
        baslib.Color(4, -1)
        baslib.LineBox(10, 100, 40, 130, 1, -1, false)
        baslib.LineBox(15, 105, 35, 125, -1, -1, true)
        baslib.LineBox(80, 130, 50, 100, 1, -1, false)
        baslib.LineBox(75, 125, 55, 105, -1, -1, true)
        baslib.LineBox(40, 140, 10, 170, 1, -1, false)
        baslib.LineBox(15, 165, 35, 145, -1, -1, true)
        baslib.LineBox(50, 170, 80, 140, 1, -1, false)
        baslib.LineBox(55, 165, 75, 145, -1, -1, true)
        baslib.Print(baslib.InputCount(1)) // wait keyboard
        baslib.Println(``)
}

函数 baslib.line() 是负责绘制的主要部分，可在此处使用：

https://github.com/udhos/basgo/blob/mainthread/baslib/graphics.go#l269

解决方案

实际上，我认为问题比我最初想象的要简单：每次绘制一条线时，您都会调用 window.SwapBuffers() ，而实际上您应该在一帧结束时调用它一次。

现代系统上的缓冲区交换意味着“在显示器上显示帧缓冲区的当前内容，并为我提供一个新的屏幕外缓冲区来绘制”。没有定义这个新的离屏缓冲区是否为空，因为 OpenGL 标准无论如何都会调用 glClear。在我的双启动笔记本电脑上进行的快速 C 测试确实对 Linux 和 MS Windows 有不同的行为。

因此，您的程序绘制第一行，交换缓冲区，绘制第二行，再次交换缓冲区。在我看来，Linux 实现似乎保留了帧缓冲区内容，因此当绘制第二行时，第一行仍然存在。在 MS Windows 上，我猜想新的帧缓冲区已被清除，因此第一行会非常非常短暂地“显示”，然后被第二个帧缓冲区覆盖，仅显示第二行。

好了，本文到此结束，带大家了解了《在Windows 10上无法绘制Golang OpenGL线，但Linux可以》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！