This came up during code review in https://golang.org/cl/171025. Backport the improvements to the upstream copies of those packages. These are better names for these Go packages. The previous names were an attempt at leveraging the familiarity with Apple's API prefixes (i.e., AppKit identifiers tend to have "NS" prefix, Core Animation API identifiers tend to have "CA" prefixes). However, that isn't as useful here because those prefixes are not very consistent or recognizable when turned into Go package names. Create a helper to convert from bool to C.BOOL and use it instead of more verbose switches. Other people seem to like this style better.
It has become unnecessary after the switch from GLFW v3.2 to v3.3, because Window.GetCocoaWindow now returns unsafe.Unsafe directly.
These were needed for a Metal API-based driver for x/exp/shiny.
Decide on and document the minimum supported macOS version as 10.13. macOS 10.13 runs on the same hardware as 10.12, so anyone with 10.12 can update to 10.13 and use this package. I don't have access to older versions of macOS to test with, nor do I have the bandwidth to support them.
The goal of this change is to make it possible to use package mtl to render to a window at interactive framerates (e.g., at 60 FPS, assuming a 60 Hz display with vsync on). It adds the minimal API that is needed. A new movingtriangle example is added as a demonstration of this functionality. It opens a window and renders a triangle that follows the mouse cursor. Much of the needed API comes from Core Animation, AppKit frameworks, rather than Metal. Avoid adding that to mtl package; instead create separate packages. For now, they are hidden in internal to avoid committing to a public API and import path. After gaining more confidence in the approach, they can be factored out and made public.
It might be desirable for some users to be able to run a command that outputs information about Metal devices without having to write code. This is similar to utilities such as glfwinfo, glewinfo, etc.
This way, executing it with -help flag prints usage, rather than running unconditionally. Remove an unhelpful blank line.