Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Unify update and render into a single step #7574

Merged
merged 1 commit into from
Jan 6, 2017
Merged

Conversation

kkaefer
Copy link
Member

@kkaefer kkaefer commented Jan 2, 2017

Update only when, and just prior to, rendering, giving no opportunity to interleave unexpected state changes. Abandon the use of AsyncTask in continuous mode; instead call backend.invalidate() whenever something occurs that needs to trigger a update/render, relying on the platform implementation of invalidate to perform coalescing.

This fixes #7040.

/cc @jfirebaugh @pveugen

@mention-bot
Copy link

@kkaefer, thanks for your PR! By analyzing this pull request, we identified @jfirebaugh, @1ec5 and @incanus to be potential reviewers.

}

if (style->hasTransitions()) {
onUpdate(Update::RecalculateStyle);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this and the painter->needsAnimation() case, should we be |'ing Update::RecalculateStyle / Update::Repaint with flags (from updateTransitions)?

view,
annotationManager->getSpriteAtlas());

painter->cleanup();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can Painter::cleanup be called internally at the end of Painter::render?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the static rendering case, we're calling cleanup after the callback (meaning that we don't have to wait for the cleanup to happen before the invoking implementation can do something with the result)

@jfirebaugh
Copy link
Contributor

Labels are failing to fade in/out all the way:

image

@kkaefer
Copy link
Member Author

kkaefer commented Jan 4, 2017

Looks like this is caused by calling invalidate and triggering a new frame while the current frame is still in progress. In GLFW, we are setting the dirty flag to false after we rendered (which means it's always set to false), but we could just revert that. However, other platforms like macOS and iOS also suffer from the similar issue. I'll move the update call back to using a util::AsyncTask

Update only when, and just prior to, rendering, giving no opportunity to interleave unexpected state changes. This means that every time anything about the state is changed, we'll have to attempt a render to reflect that change. In the case of continuous rendering this has happened before this change as well, but it leaves no room for time to pass between an update and a render. In the case of still image rendering, a render call will only actually paint something to the view when all resources have been loaded.
backend.invalidate();
} else {
renderStill();
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved the invalidation call back to happen after the async. The change to master is now that before, we had a render() => asyncUpdate() => update() => invalidate() => render() flow. It's now shortened to render() => asyncInvalidate() => invalidate() => update+render()

@jfirebaugh
Copy link
Contributor

I'm noticing lots of unpleasant label flickering when testing this, but I suspect it's a pre-existing issue such as #7026.

@kkaefer
Copy link
Member Author

kkaefer commented Jan 5, 2017

@jfirebaugh yes; I re-checked with master and saw the same types of flickering as documented in #7026

@jfirebaugh jfirebaugh merged commit b6894dd into master Jan 6, 2017
@jfirebaugh jfirebaugh deleted the update-render branch January 6, 2017 20:03
1ec5 added a commit that referenced this pull request Jan 16, 2017
1ec5 added a commit that referenced this pull request Jan 19, 2017
Updated changelogs to mention #7446, #7356, #7465, #7616, #7445, #7444, #7526, #7586, #7574, and #7770. Also corrected the blurb about #7711.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants