yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

core/renderloop: don't do triple buffering with vrr or tearing

Browse source 
While in theory it could be useful with both, I'm not sure that it makes sense
in practice, and the current triple buffering logic doesn't support it.

BUG: 487605
This commit is contained in:
Xaver Hugl 2024-06-05 16:38:31 +02:00
parent 54473f03ba
commit 76739f1f2f
1 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
src/core/renderloop.cpp
View file

@ -202,13 +202,15 @@ void RenderLoop::scheduleRepaint(Item *item, RenderLayer *layer)
return;
}
const bool vrr = d->presentationMode == PresentationMode::AdaptiveSync || d->presentationMode == PresentationMode::AdaptiveAsync;
if (vrr && workspace()->activeWindow() && d->output) {
const bool tearing = d->presentationMode == PresentationMode::Async || d->presentationMode == PresentationMode::AdaptiveAsync;
if ((vrr || tearing) && workspace()->activeWindow() && d->output) {
Window *const activeWindow = workspace()->activeWindow();
if ((item || layer) && activeWindow->isOnOutput(d->output) && activeWindow->surfaceItem() && item != activeWindow->surfaceItem() && activeWindow->surfaceItem()->frameTimeEstimation() <= std::chrono::nanoseconds(1'000'000'000) / 30) {
return;
}
}
if (d->pendingFrameCount < d->maxPendingFrameCount && !d->inhibitCount) {
const int effectiveMaxPendingFrameCount = (vrr || tearing) ? 1 : d->maxPendingFrameCount;
if (d->pendingFrameCount < effectiveMaxPendingFrameCount && !d->inhibitCount) {
d->scheduleNextRepaint();
} else {
d->delayScheduleRepaint();