support delayed blocker #1720
support delayed blocker #1720
Conversation
cmeissl
force-pushed
the
feature/delayed_blocker
branch
2 times, most recently
from
d125eef to
2c2ec49
Compare
| ready_transactions.push(self.transactions.remove(i)); | ||
| let transaction = &mut self.transactions[i]; | ||
|
|
||
| transaction.notify_blockers(); |
There was a problem hiding this comment.
Won't this get called over and over after the immediate blockers are done but before the delayed blockers are done?
There was a problem hiding this comment.
Depends on the impl of the delayed blocker and the precense of other delayed blockers. It could unblock from within notify and if it is the last one it would not be called again. But yes, it could get notified multiple times until the transaction completed. Maybe something worth documenting on the notify function. Just FYI, I also evaluated a design based on a callback which could place additional blockers but that had its own shortcomings.
| { | ||
| let signaled = self.ready.swap(true, std::sync::atomic::Ordering::Acquire); | ||
| if !signaled { | ||
| self.ping.ping(); |
There was a problem hiding this comment.
IIRC in niri I didn't use the Ping source for the actual ready notification because it would arrive only on the next event loop iteration. I'm not sure if this is a problem here.
There was a problem hiding this comment.
Interesting. I am also not sure this is a problem in this case. We could use a channel instead maybe?
cmeissl
force-pushed
the
feature/delayed_blocker
branch
from
2c2ec49 to
3f660ed
Compare
This PR extends the existing
BlockerAPI with aBlockerKind. Allowing to put blockers into two groups,ImmediateandDelayed.Blockers withBlockerKind::Delayedwill only be evaluated once allImmediatehave been cleared.After all
Immediateblockers have been cleared allBlockers will be notified, allowing delayed blockers to make a decision based on that.All blockers still need to be cleared for the transaction to be unblocked.
Additionally the PR adds a reference implementation of a delayed blocker,
SurfaceBarrier.One example for this is implementing animation transactions spanning multiple otherwise unrelated surfaces.
While this can be implemented without the
SurfaceBarrier, it might help to enhance synchronization when some other blockers further delay the buffer.A compositor could place a
Immediateblocker, like for example a simpleBarrier, on each surface participating in the animation transaction and also register it in aSurfaceBarrierwith the same scope as the animation transaction.Once the
Immediateblocker representing the transaction is cleared, the blocker in theSurfaceBarrierwill try to resolve and ping the compositor once it completed.cc @YaLTeR