-
Notifications
You must be signed in to change notification settings - Fork 1.3k
split renderSync and transition nudging to allow client view syncing #1813
Conversation
Per chat, @kkaefer says we should probably snapshot time and use that to be consistent through the render of a frame and update of transitions, instead of having varying notions of time throughout. This PR is more of a workaround of that. |
@incanus Instead of splitting this up, can you implement this by updating to latest master and doing the syncing when the view receives |
Duh, yeah, great idea. We'll just need some tests to make sure that the transitions stay after the closing notification, though. |
Just talked this out with @kkaefer — @jfirebaugh, this won't work, because we do everything synchronously. So the order of operations is:
@kkaefer is going to look today & tomorrow into #1813 (comment) to solve this. |
By "synchronous" you mean the notification is dispatched from the rendering thread, while the view syncing needs to happen on the main thread? |
Yeah, sorry, the post-render-post-update cycle all happens inline in the map thread, and the view update needs to happen on the main thread in between steps 3 and 4. |
It might make sense to go with this spilt for b3 for an easy win and circle back on the refactor work. |
Going to apply this to the |
Picking up from stuff learned in #1125 (comment), this breaks the current
renderSync
into two parts — the actual render call and anudgeTransitions
which moves a step in theTransform
, possibly callingMap::update
if needed.The reason for this is needing to sync client-side view (i.e.
UIView
objects) positions with the GL map, and that step needing to come in between these two to remain in sync.Todo: