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

Open
crawshaw opened this Issue Oct 7, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@crawshaw
Contributor

crawshaw commented Oct 7, 2015

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?

@crawshaw crawshaw self-assigned this Oct 7, 2015

@rsc rsc added this to the Unreleased milestone Oct 23, 2015

@db47h

This comment has been minimized.

db47h commented Nov 13, 2015

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

@crawshaw

This comment has been minimized.

Contributor

crawshaw commented Nov 13, 2015

@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.

@crawshaw crawshaw changed the title from x/mobile/app: sender for Publish? to x/mobile: dedicated publish.Event type? Nov 13, 2015

@db47h

This comment has been minimized.

db47h commented Nov 13, 2015

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

This comment has been minimized.

Contributor

crawshaw commented Nov 13, 2015

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

This comment has been minimized.

db47h commented Nov 13, 2015

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.

@gopherbot gopherbot added the mobile label Jul 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment