2
0
mirror of synced 2025-02-24 15:28:28 +00:00
mobile/app/x11.go

124 lines
2.6 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.
//go:build linux && !android
// +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.
*/
/*
#cgo LDFLAGS: -lEGL -lGLESv2 -lX11
void createWindow(void);
void processEvents(void);
void swapBuffers(void);
*/
import "C"
import (
"runtime"
"time"
"golang.org/x/mobile/event/lifecycle"
"golang.org/x/mobile/event/paint"
"golang.org/x/mobile/event/size"
"golang.org/x/mobile/event/touch"
"golang.org/x/mobile/geom"
)
func init() {
theApp.registerGLViewportFilter()
}
func main(f func(App)) {
runtime.LockOSThread()
workAvailable := theApp.worker.WorkAvailable()
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 16:41:48 +10:00
C.createWindow()
// TODO: send lifecycle events when e.g. the X11 window is iconified or moved off-screen.
theApp.sendLifecycle(lifecycle.StageFocused)
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 16:41:48 +10:00
// TODO: translate X11 expose events to shiny paint events, instead of
// sending this synthetic paint event as a hack.
theApp.eventsIn <- paint.Event{}
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 16:41:48 +10:00
go func() {
f(theApp)
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 16:41:48 +10:00
}()
// TODO: can we get the actual vsync signal?
ticker := time.NewTicker(time.Second / 60)
defer ticker.Stop()
var tc <-chan time.Time
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 16:41:48 +10:00
for {
select {
case <-donec:
return
case <-workAvailable:
theApp.worker.DoWork()
case <-theApp.publish:
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 16:41:48 +10:00
tc = ticker.C
case <-tc:
tc = nil
theApp.publishResult <- PublishResult{}
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 16:41:48 +10:00
}
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 16:41:48 +10:00
// TODO(nigeltao): don't assume 72 DPI. DisplayWidth and DisplayWidthMM
// is probably the best place to start looking.
pixelsPerPt := float32(1)
theApp.eventsIn <- size.Event{
WidthPx: w,
HeightPx: h,
WidthPt: geom.Pt(w),
HeightPt: geom.Pt(h),
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 16:41:48 +10:00
PixelsPerPt: pixelsPerPt,
}
}
func sendTouch(t touch.Type, x, y float32) {
theApp.eventsIn <- touch.Event{
X: x,
Y: y,
Sequence: 0, // TODO: button??
Type: t,
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 16:41:48 +10:00
}
}
//export onTouchBegin
func onTouchBegin(x, y float32) { sendTouch(touch.TypeBegin, x, y) }
//export onTouchMove
func onTouchMove(x, y float32) { sendTouch(touch.TypeMove, x, y) }
//export onTouchEnd
func onTouchEnd(x, y float32) { sendTouch(touch.TypeEnd, 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 16:41:48 +10: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 16:41:48 +10:00
if stopped {
return
}
stopped = true
theApp.sendLifecycle(lifecycle.StageDead)
theApp.eventsIn <- stopPumping{}
}