|author||Dmitri Shuralyov <email@example.com>||Mon Apr 08 01:09:37 2019 -0400|
|committer||Nigel Tao <firstname.lastname@example.org>||Thu Sep 19 03:57:09 2019 +0000|
shiny/driver/mtldriver: add start of a Metal API-based driver The OpenGL API has been deprecated on macOS as of version 10.14.¹ The replacement for OpenGL on macOS is the Metal API.² This change adds the start of a Metal API-based shiny driver. It can be activated by specifying the -tags=metal build tag on macOS 10.13+. For example: go run -tags='example metal' golang.org/x/exp/shiny/example/icongallery The goal of this CL has been to create an MVP. As a result, the focus is on simplicity and correctness. Performance optimizations can come later. The Metal API is currently used only to present the final pixels to the screen. All rendering is performed on the CPU via the image/draw algorithms (see https://blog.golang.org/go-imagedraw-package). Future work is to use mtl.Buffer, mtl.Texture, etc., to do more of the rendering work on the GPU. From what I've observed so far, the Metal API is looking to be a great fit for implementing the screen.Screen interface. But we'll learn more when it's used to a greater extent of its full performance potential. GLFW v3.2.1 is used for window creation, receiving input events, etc. Package dmitri.shuralyov.com/gpu/mtl is used for Metal API access. Helper packages for Apple's Core Animation and AppKit APIs are copied. References: ¹ https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes?language=objc#3035786 ² https://developer.apple.com/metal/ Change-Id: I0e02d660b776820ca499bfe7d67e47a9866d530c Reviewed-on: https://go-review.googlesource.com/c/exp/+/171025 Run-TryBot: Dmitri Shuralyov <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Nigel Tao <email@example.com>
This subrepository holds experimental and deprecated (in the
old directory) packages.
The idea for this subrepository originated as the
pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to
go get these packages.
Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.
In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)