glow
glow copied to clipboard
go-gl
Remove Cgo dependency on Windows
Fixes https://github.com/go-gl/gl/issues/109
Design Document
https://docs.google.com/document/d/1mqquznil9fR2amtb3eTC2ObCx3A8Af_5INqKjO-pKDg/edit?usp=sharing
tl;dr
I propose to eliminate Cgo usages on Windows from go-gl/gl by fixing go-gl/glow to generate code using syscall.Syscall.
That's really sad that there has not been any feedback in the last 22 days. This change is really important (at least to me) e.g. in order to make compiling time shorten on Windows.
Hi @hajimehoshi, thanks very much for your contribution. Sorry it is taking time, but please be aware that no one is paid to maintain these packages. It's a best effort in our spare time and we can only give so much. Please have patience and faith that we will get to it. Feel free to continue to send pings!
@pwaller @kjozic or @errcw
Are any of you able to set aside some time and review this? Being able to not rely on CGo on Windows would be amazing and help with simplifying the build process of my game engine for less experienced users.
I think I have addressed all the issues. Please take a look. Thank you!
@hajimehoshi thank you very much for this. I can't understand why it has been abandoned.
I created a pull request on your nocgo branch to sync with master, implementing overloads.
Moreover, I found a bug, not linked to overloads, in function:
func DebugMessageCallback(callback DebugProc, userParam unsafe.Pointer) {
syscall.Syscall(gpDebugMessageCallback, 2, syscall.NewCallbackCDecl(callback), uintptr(userParam), 0)
}
panic: compileCallback: expected function with one uintptr-sized result
This happens while creating a debug context with glfw 3.3; it works fine with cgo version.
If I succeed in fixing it, I will make another pull request on your branch.
I would like everyone to take notice that using syscall will double the call overhead, because syscall always calls GetLastError() on Windows, even if you use it to invoke non-WINAPI functions. If your CPU is bottlenecking (which is likely because we already experience a ~70ns overhead due to CGO) it would then bottleneck doubly, without gaining anything in the process. This will then further cement the fact that Golang projects which use OpenGL must be able to make do with a fraction of the calls that a C program could use.
Does this change limit glow only to generating Golang GL bindings using desktop OpenGL? Thanks
thank you very much for this. I can't understand why it has been abandoned.
Oh I forgot I created this PR... I was waiting for the reviews but reviewers seemed pretty busy.
If there are reviewers, I'm fine to continue this PR.
We at Fyne would certainly be interested at testing this once it is ready. It has been suggested a few times in the past that we should remove CGo on Windows (see https://github.com/fyne-io/fyne/issues/911).
