Skip to content
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

[Android] Stop calling eglSwapBuffers immediately. #4252

Merged
merged 1 commit into from
Oct 14, 2024

Conversation

jellefoks
Copy link
Member

Since we're seeing ANRs at SCREEN_OFF where the rasterizer thread appears to be hanging during eglSwapBuffers, this change attempts to avoid those ANRs by immediately skip calls to eglSwapBuffers when a surfaceDestroyed event is received, until a the next SurfaceCreated. Since Cobalt uses GameActivity, those are received in calls to OnNativeWindowDestroyed respectively OnNativeWindowCreated.

b/225209442

Since we're seeing ANRs at SCREEN_OFF where the rasterizer thread appears to
be hanging during eglSwapBuffers, this change attempts to avoid those ANRs
by immediately skip calls to eglSwapBuffers when a surfaceDestroyed event is
received, until a the next SurfaceCreated.  Since Cobalt uses GameActivity,
those are received in calls to OnNativeWindowDestroyed respectively
OnNativeWindowCreated.

b/225209442
@jellefoks jellefoks marked this pull request as ready for review October 11, 2024 21:22
@jellefoks
Copy link
Member Author

Cherry-pick of #3076. I believe this deserves a chance.

@jellefoks jellefoks enabled auto-merge (squash) October 11, 2024 21:23
@@ -41,6 +41,9 @@
namespace starboard {
namespace android {
namespace shared {

atomic_bool g_block_swapbuffers;
Copy link
Member

@kaidokert kaidokert Oct 12, 2024

Choose a reason for hiding this comment

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

Does this need to be an atomic ? It's only written to from Android UI thread and read in renderer thread, it can just be a bool ?

Copy link
Member Author

Choose a reason for hiding this comment

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

It has to be atomic exactly because it's read from a different thread than from where it's written. It ensures that it's not read while being written and potentially only partially written, in addition to using memory barriers to make sure it's not using a stale (cached) value.

Copy link
Member

@kaidokert kaidokert Oct 14, 2024

Choose a reason for hiding this comment

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

But there are no memory barriers here. Just making it atomic doesn't guarantee it's correctly reflected between threads and cores. If you want to absolutely ensure it's correct, just use a lock.

Copy link
Member Author

@jellefoks jellefoks Oct 14, 2024

Choose a reason for hiding this comment

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

The load() and store() of atomic_bool that are used to access it include barriers as needed.

See starboard/common/atomic.h lines 390 and 392.

Copy link
Contributor

@zhongqiliang zhongqiliang left a comment

Choose a reason for hiding this comment

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

This was submitted to Trunk, LGTM to submit to lts 25.

@jellefoks jellefoks merged commit 7014813 into youtube:25.lts.1+ Oct 14, 2024
300 of 301 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants