Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x/mobile: dedicated publish.Event type? #12869
@db47h regarding Publish (the last of the three questions from the original TODO), yes, the question is should it look more like Upload:
That is the signature would become
The most interesting question here is should we have a dedicated publish.Event type? I don't know yet.
These questions are mostly being considered in x/exp/shiny and ported to x/mobile/app, as the requirements in a multi-window system are harder.
The only reason I see to add a sender parameter to Publish is an eventual support of multi-window in x/mobile.
As for a publish event: right now Publish() could take up to 1/60s to return, as a result this throttles the event loop whenever a paint event is handled. This may not be desirable for example in applications that need to handle input events ASAP (gesture recognition/reading sensors) or that struggle to maintain 60fps: suppose that physics+drawing takes just over 1/60s (say 0.02s), plus Publish() force waiting on the next vsync, the app would be stuck at 30fps. If Publish() was asynchronous, it could start updating its world and redraw immediately after calling it and achieve a near average of 1/50fps (as well as having more spare time to handle more events).
EDIT: I suppose here that making Publish asynchronous mandates a dedicated publish.Event
It is indeed possible to call publish from a different goroutine: https://gist.github.com/db47h/0bb10754d2993c0526e1
You can ignore the cruft with event waiting or polling depending on lifecycle stage. I was exploring how to eventually support the "pause" state on Android or automatically pause the app and display a pause screen on desktop when it has lost focus.
This example is biased towards desktops: it runs as fast as possible, the game world is updated by fixed time steps and rendering happens when possible.
Well, right now onUpdate is only changing the color of the triangle but I intend to update this so the user can fling the triangle around so we can show something that justifies the complexity of the thing.
The interesting bit is in "drawing whenever possible": since I do not want to wait for app.Publish to complete, I used a goroutine as you suggested, and trigger the Publish by sending on a.pubC (happens at the end of onPaint()). If the next attempt to Publish happens before the first one has completed, my main loop would block, so I had to implement a published notification (it sends a custom event via app.Send()).
I guess a more mobile/energy friendly app might just be happy with a blocking version of app.Publish, so I don't know either if making a app.Publish asynchronous is a good idea or worth the added complexity for all users.