New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/mobile: dedicated publish.Event type? #12869
Comments
Do you mean to have app.Publish() return immediately and have the publish result sent via a new publish.Event? |
@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 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 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. |
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. |
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?
The text was updated successfully, but these errors were encountered: