raylib-go
raylib-go copied to clipboard
gen2brain
Examples assume they run on a single thread
Raylib drawing commands aren't thread-safe - which isn't a huge deal, since OpenGL isn't to begin with - but since the examples don't lock an OS thread, drawing commands could potentially be issued on a different thread after garbage collection (as in this issue).
The quick and dirty way of fixing this would be to manually call runtime.LockOSThread in the examples. However, this seems like a common enough gotcha with Go and graphics libraries that it might be a good idea to handle it in the binding somehow - possibly by providing a mainthread-style helper?
There is this page that can be linked from README https://github.com/golang/go/wiki/LockOSThread . SDL bindings has this helper https://github.com/veandco/go-sdl2/commit/bc9d5d1882528a19da2e638decae0bc239e78cfd with some examples how to use it https://github.com/veandco/go-sdl2/blob/master/examples/render_goroutines/render_goroutines.go but now sure if that can work here, will need some time to test.
An alternative to the helper would be to create a Context struct (or similar) maintaining an internal work queue, similar to what mobile/gl does, with all raylib functions being defined as methods on that struct. That'd be a little more work, but it would remove the need to wrap everything in Do calls.
e: thinking on it a bit, I think it should be possible to fork and lock a thread in InitWindow, make it listen on a package-level work queue, with functions rewritten to enqueue work on that thread. That would allow 100% API compatibility at the cost of adding communication overhead. Will try to get a proof of concept running when I have the time.
@gen2brain
I think we can close this issue after nearly 6 years.
Its fixed with using runtime.LockOSThread(): https://github.com/gen2brain/raylib-go/blob/master/raylib/raylib.go#L51
