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

fix busyloop while waiting for WlBuffers to be released #206

Merged
merged 1 commit into from
Feb 13, 2024

Conversation

LGFae
Copy link
Owner

@LGFae LGFae commented Feb 13, 2024

We changed from SlotPool to Multipool, which let us fix the busyloop. Suggested by @YaLTeR.

Fixes #202.

We changed from SlotPool to Multipool, which let us fix the busyloop.
@LGFae
Copy link
Owner Author

LGFae commented Feb 13, 2024

Just finished testing with niri. It appears to be working.

@LGFae LGFae merged commit 0105341 into main Feb 13, 2024
@LGFae LGFae deleted the fix-busyloop-on-waiting-wlbuffer-release branch February 13, 2024 18:03
@YaLTeR
Copy link

YaLTeR commented Feb 13, 2024

Just gave it a try, while it seems to work, the damage tracking or something appears to be broken? There are some buffer glitches.

@YaLTeR
Copy link

YaLTeR commented Feb 13, 2024

out.mp4

@LGFae
Copy link
Owner Author

LGFae commented Feb 13, 2024

Jesus Christ. I wonder why that didn't show up over here? I tested it inside River, maybe I should have spawned a new tty. I'll do that now.

@LGFae
Copy link
Owner Author

LGFae commented Feb 13, 2024

Hmm. I am actually incapable of reproducing that. I thought this would damage the entire surface:

        let surface = self.layer_surface.wl_surface();
        surface.attach(Some(buf), 0, 0);
        surface.damage_buffer(0, 0, width, height);
        surface.commit();

So, because we damage the entire surface every time, I don't think it's the damage tracking...

@YaLTeR
Copy link

YaLTeR commented Feb 13, 2024

Yeah, weird.. Maybe something to do with buffer format?

@LGFae
Copy link
Owner Author

LGFae commented Feb 13, 2024

The buffer format didn't change. It remains Xrgb8888, which is guaranteed to exist by the protocol.

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.

niri: swww gets stuck in infinite loop with 100% cpu usage
2 participants