mobile/app/x11.go

117 lines
2.3 KiB
Go
Raw Normal View History

// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// +build linux,!android
package app
/*
Simple on-screen app debugging for X11. Not an officially supported
development target for apps, as screens with mice are very different
than screens with touch panels.
On Ubuntu 14.04 'Trusty', you may have to install these libraries:
sudo apt-get install libegl1-mesa-dev libgles2-mesa-dev libx11-dev
*/
/*
#cgo LDFLAGS: -lEGL -lGLESv2 -lX11
void createWindow(void);
void processEvents(void);
void swapBuffers(void);
*/
import "C"
import (
"runtime"
"time"
"golang.org/x/mobile/event"
"golang.org/x/mobile/geom"
"golang.org/x/mobile/gl"
)
func init() {
registerGLViewportFilter()
}
func main(f func(App)) {
runtime.LockOSThread()
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>
2015-06-23 06:41:48 +00:00
C.createWindow()
// TODO: send lifecycle events when e.g. the X11 window is iconified or moved off-screen.
sendLifecycle(event.LifecycleStageFocused)
donec := make(chan struct{})
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>
2015-06-23 06:41:48 +00:00
go func() {
f(app{})
close(donec)
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>
2015-06-23 06:41:48 +00:00
}()
// TODO: can we get the actual vsync signal?
ticker := time.NewTicker(time.Second / 60)
defer ticker.Stop()
tc := ticker.C
for {
select {
case <-donec:
return
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>
2015-06-23 06:41:48 +00:00
case <-gl.WorkAvailable:
gl.DoWork()
case <-endDraw:
C.swapBuffers()
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>
2015-06-23 06:41:48 +00:00
tc = ticker.C
case <-tc:
tc = nil
eventsIn <- event.Draw{}
}
C.processEvents()
}
}
//export onResize
func onResize(w, h int) {
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>
2015-06-23 06:41:48 +00:00
// TODO(nigeltao): don't assume 72 DPI. DisplayWidth and DisplayWidthMM
// is probably the best place to start looking.
pixelsPerPt = 1
eventsIn <- event.Config{
Width: geom.Pt(w),
Height: geom.Pt(h),
PixelsPerPt: pixelsPerPt,
}
}
func sendTouch(c event.Change, x, y float32) {
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>
2015-06-23 06:41:48 +00:00
eventsIn <- event.Touch{
ID: 0, // TODO: button??
Change: c,
Loc: geom.Point{
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>
2015-06-23 06:41:48 +00:00
X: geom.Pt(x / pixelsPerPt),
Y: geom.Pt(y / pixelsPerPt),
},
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>
2015-06-23 06:41:48 +00:00
}
}
//export onTouchStart
func onTouchStart(x, y float32) { sendTouch(event.ChangeOn, x, y) }
//export onTouchMove
func onTouchMove(x, y float32) { sendTouch(event.ChangeNone, x, y) }
//export onTouchEnd
func onTouchEnd(x, y float32) { sendTouch(event.ChangeOff, x, y) }
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>
2015-06-23 06:41:48 +00:00
var stopped bool
//export onStop
func onStop() {
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>
2015-06-23 06:41:48 +00:00
if stopped {
return
}
stopped = true
sendLifecycle(event.LifecycleStageDead)
eventsIn <- stopPumping{}
}