tree 6e2bb01b0bcf1fd41e7a873ff51b2a3b42ae5db7
parent 0a8a8b8cb6c432b75410dee70daf34030e4ce9a1
author Nigel Tao <nigeltao@golang.org> 1435041708 +1000
committer Nigel Tao <nigeltao@golang.org> 1435304597 +0000

app: use one thread for both GL and other UI C code.

This change will break Darwin. I have only built and tested this on
desktop linux and Android linux. A follow-up CL will fix Darwin.

Currently, OpenGL gets its own thread, and UI C code (e.g. the Android
event loop, or the X11 event loop) gets its own thread. This relies on
multiple system-provided UI-related C libraries working nicely together,
even when running on different threads. Keeping all the C code on the
one thread seems more sound.

As side-effects:
  - In package app/debug, DrawFPS now takes an explicit Config.
  - In package app, some callbacks now take an explicit Config.
  - In package exp/sprite, Render now takes an explicit Config.
  - In package event, there are new events (Config, Draw, Lifecycle),
    and an event filter mechanism to replace multiple app Callbacks.
  - In package geom, the deprecated Width, Height and PixelsPerPt global
    variables were removed in favor of an event.Config that is
    explicitly passed around (and does not require mutex-locking).
    Converting a geom.Pt to pixels now requires passing a pixelsPerPt.
  - In package gl, the Do, Start and Stop functions are removed, as well
    as the need to call Start in its own goroutine. There is no longer a
    separate GL thread. Instead, package app explicitly performs any GL
    work (gl.DoWork) when some is available (gl.WorkAvailable).
  - In package gl/glutil, Image.Draw now takes an explicit Config.

Callbacks are no longer executed on 'the UI thread'.

Changing the app programming model from callbacks to events (since a
channel of events works with select) will be a follow-up change.

Change-Id: Id9865cd9ee1c45a98c613e9021a63c17226a64b1
Reviewed-on: https://go-review.googlesource.com/11351
Reviewed-by: David Crawshaw <crawshaw@golang.org>