在Linux而非Windows10上绘制了Golang OpenGL线

Question

I am using the same OpenGL code written in Golang to draw two lines in a 640x480 pixel space. I am puzzled because both lines are drawn correctly in Linux, but only one of them is drawn in Windows10. What could cause that difference in OpenGL behavior?

• Line 1: 0,0 - 639,479 (works only on Linux)
• Line 2: 50,0 - 0,50 (works on both Linux and Windows10)

On Linux, both Lines are drawn correctly:

App logs from 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

On Windows10, only the second line is drawn:

App logs from 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

This is the full source code for the app:

$ 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(``)
}

Function baslib.Line() is the main portion responsible for the draw, and it is available here:

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

Answer 1

Actually I think the problem is simpler than I first thought: you are calling window.SwapBuffers() each time you draw a line, when you really should just be calling it once at the end of a frame.

A buffer swap on a modern system means "show the current contents of the framebuffer on the display and give me a new offscreen buffer to draw on". Whether or not this new offscreen buffer is blank or not isn't defined, since the OpenGL standard is to call glClear anyway. A quick C test on my dual boot laptop does have different behaviour for Linux and MS Windows.

So your program draws the first line, swaps the buffers, draws the second line, swaps the buffers again. It looks to me as if the Linux implementation is preserving the frame buffer contents, so your first line is still there when the second line is drawn. On MS Windows I guess that the new frame buffer is cleared, so the first line is "displayed" very very briefly and then overwritten by the second frame buffer with only the second line.