x/mobile: dedicated publish.Event type?

[crawshaw]

Moving a TODO from example/basic to an issue.

Should app code running a fast draw loop use a.Send(paint.Event{})? Should we have a dedicated publish.Event type? Should App.Publish take an optional event sender and send a publish.Event?

[db47h]

Do you mean to have app.Publish() return immediately and have the publish result sent via a new publish.Event?

[crawshaw]

@db47h regarding Publish (the last of the three questions from the original TODO), yes, the question is should it look more like Upload:

https://godoc.org/golang.org/x/exp/shiny/screen#Uploader

That is the signature would become app.Publish(sender Sender), it would return immediately and send a message to sender when it is done. I'm not in favor of adding this kind of complexity to the method without a good reason, and I cannot see a good reason. So count me against it for now.

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.

[db47h]

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

[crawshaw]

It is also possible to call Publish from a different goroutine and continue to process events, which is something I would like to explore as it feels more Go-like to block and spawn goroutines as necessary than to use callbacks.

[db47h]

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.