Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
/*
|
|
|
|
SPDX-FileCopyrightText: 2020 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
|
|
|
|
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "renderloop.h"
|
|
|
|
#include "renderloop_p.h"
|
2021-02-20 15:04:18 +00:00
|
|
|
#include "surfaceitem.h"
|
2022-01-18 08:35:52 +00:00
|
|
|
#include "utils/common.h"
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
2022-03-23 10:13:38 +00:00
|
|
|
template<typename T>
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
T alignTimestamp(const T ×tamp, const T &alignment)
|
|
|
|
{
|
|
|
|
return timestamp + ((alignment - (timestamp % alignment)) % alignment);
|
|
|
|
}
|
|
|
|
|
|
|
|
RenderLoopPrivate *RenderLoopPrivate::get(RenderLoop *loop)
|
|
|
|
{
|
2022-06-01 13:45:02 +00:00
|
|
|
return loop->d.get();
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
RenderLoopPrivate::RenderLoopPrivate(RenderLoop *q)
|
|
|
|
: q(q)
|
|
|
|
{
|
|
|
|
compositeTimer.setSingleShot(true);
|
2022-03-23 10:13:38 +00:00
|
|
|
QObject::connect(&compositeTimer, &QTimer::timeout, q, [this]() {
|
|
|
|
dispatch();
|
|
|
|
});
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoopPrivate::scheduleRepaint()
|
|
|
|
{
|
2021-08-12 00:23:13 +00:00
|
|
|
if (kwinApp()->isTerminating() || compositeTimer.isActive()) {
|
2021-02-20 15:04:18 +00:00
|
|
|
return;
|
|
|
|
}
|
2021-11-04 16:34:17 +00:00
|
|
|
if (vrrPolicy == RenderLoop::VrrPolicy::Always || (vrrPolicy == RenderLoop::VrrPolicy::Automatic && fullscreenItem != nullptr)) {
|
2021-02-20 15:04:18 +00:00
|
|
|
presentMode = SyncMode::Adaptive;
|
|
|
|
} else {
|
|
|
|
presentMode = SyncMode::Fixed;
|
|
|
|
}
|
|
|
|
const std::chrono::nanoseconds vblankInterval(1'000'000'000'000ull / refreshRate);
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
const std::chrono::nanoseconds currentTime(std::chrono::steady_clock::now().time_since_epoch());
|
|
|
|
|
|
|
|
// Estimate when the next presentation will occur. Note that this is a prediction.
|
2021-01-14 13:35:43 +00:00
|
|
|
nextPresentationTimestamp = lastPresentationTimestamp + vblankInterval;
|
2021-08-12 00:23:13 +00:00
|
|
|
if (nextPresentationTimestamp < currentTime && presentMode == SyncMode::Fixed) {
|
2021-01-14 13:35:43 +00:00
|
|
|
nextPresentationTimestamp = lastPresentationTimestamp
|
2022-03-23 10:13:38 +00:00
|
|
|
+ alignTimestamp(currentTime - lastPresentationTimestamp, vblankInterval);
|
2021-01-14 13:35:43 +00:00
|
|
|
}
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
|
|
|
|
// Estimate when it's a good time to perform the next compositing cycle.
|
|
|
|
const std::chrono::nanoseconds safetyMargin = std::chrono::milliseconds(3);
|
|
|
|
|
|
|
|
std::chrono::nanoseconds renderTime;
|
2022-05-12 21:17:21 +00:00
|
|
|
switch (q->latencyPolicy()) {
|
2022-05-29 00:08:10 +00:00
|
|
|
case LatencyExtremelyLow:
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
renderTime = std::chrono::nanoseconds(long(vblankInterval.count() * 0.1));
|
|
|
|
break;
|
|
|
|
case LatencyLow:
|
|
|
|
renderTime = std::chrono::nanoseconds(long(vblankInterval.count() * 0.25));
|
|
|
|
break;
|
|
|
|
case LatencyMedium:
|
|
|
|
renderTime = std::chrono::nanoseconds(long(vblankInterval.count() * 0.5));
|
|
|
|
break;
|
|
|
|
case LatencyHigh:
|
|
|
|
renderTime = std::chrono::nanoseconds(long(vblankInterval.count() * 0.75));
|
|
|
|
break;
|
|
|
|
case LatencyExtremelyHigh:
|
|
|
|
renderTime = std::chrono::nanoseconds(long(vblankInterval.count() * 0.9));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-11-28 15:12:38 +00:00
|
|
|
switch (options->renderTimeEstimator()) {
|
|
|
|
case RenderTimeEstimatorMinimum:
|
|
|
|
renderTime = std::max(renderTime, renderJournal.minimum());
|
|
|
|
break;
|
|
|
|
case RenderTimeEstimatorMaximum:
|
|
|
|
renderTime = std::max(renderTime, renderJournal.maximum());
|
|
|
|
break;
|
|
|
|
case RenderTimeEstimatorAverage:
|
|
|
|
renderTime = std::max(renderTime, renderJournal.average());
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
std::chrono::nanoseconds nextRenderTimestamp = nextPresentationTimestamp - renderTime - safetyMargin;
|
|
|
|
|
|
|
|
// If we can't render the frame before the deadline, start compositing immediately.
|
|
|
|
if (nextRenderTimestamp < currentTime) {
|
|
|
|
nextRenderTimestamp = currentTime;
|
|
|
|
}
|
|
|
|
|
|
|
|
const std::chrono::nanoseconds waitInterval = nextRenderTimestamp - currentTime;
|
|
|
|
compositeTimer.start(std::chrono::duration_cast<std::chrono::milliseconds>(waitInterval));
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoopPrivate::delayScheduleRepaint()
|
|
|
|
{
|
|
|
|
pendingReschedule = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoopPrivate::maybeScheduleRepaint()
|
|
|
|
{
|
|
|
|
if (pendingReschedule) {
|
|
|
|
scheduleRepaint();
|
|
|
|
pendingReschedule = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-29 11:24:38 +00:00
|
|
|
void RenderLoopPrivate::notifyFrameFailed()
|
|
|
|
{
|
|
|
|
Q_ASSERT(pendingFrameCount > 0);
|
|
|
|
pendingFrameCount--;
|
|
|
|
|
|
|
|
if (!inhibitCount) {
|
|
|
|
maybeScheduleRepaint();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
void RenderLoopPrivate::notifyFrameCompleted(std::chrono::nanoseconds timestamp)
|
|
|
|
{
|
|
|
|
Q_ASSERT(pendingFrameCount > 0);
|
|
|
|
pendingFrameCount--;
|
|
|
|
|
|
|
|
if (lastPresentationTimestamp <= timestamp) {
|
|
|
|
lastPresentationTimestamp = timestamp;
|
|
|
|
} else {
|
2021-10-06 19:49:21 +00:00
|
|
|
qCWarning(KWIN_CORE,
|
|
|
|
"Got invalid presentation timestamp: %lld (current %lld)",
|
|
|
|
static_cast<long long>(timestamp.count()),
|
|
|
|
static_cast<long long>(lastPresentationTimestamp.count()));
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
lastPresentationTimestamp = std::chrono::steady_clock::now().time_since_epoch();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!inhibitCount) {
|
|
|
|
maybeScheduleRepaint();
|
|
|
|
}
|
|
|
|
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT q->framePresented(q, timestamp);
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoopPrivate::dispatch()
|
|
|
|
{
|
|
|
|
// On X11, we want to ignore repaints that are scheduled by windows right before
|
|
|
|
// the Compositor starts repainting.
|
|
|
|
pendingRepaint = true;
|
|
|
|
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT q->frameRequested(q);
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
|
|
|
|
// The Compositor may decide to not repaint when the frameRequested() signal is
|
|
|
|
// emitted, in which case the pending repaint flag has to be reset manually.
|
|
|
|
pendingRepaint = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoopPrivate::invalidate()
|
|
|
|
{
|
|
|
|
pendingReschedule = false;
|
|
|
|
pendingFrameCount = 0;
|
|
|
|
compositeTimer.stop();
|
|
|
|
}
|
|
|
|
|
2022-06-01 13:45:02 +00:00
|
|
|
RenderLoop::RenderLoop()
|
|
|
|
: d(std::make_unique<RenderLoopPrivate>(this))
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
RenderLoop::~RenderLoop()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::inhibit()
|
|
|
|
{
|
|
|
|
d->inhibitCount++;
|
|
|
|
|
|
|
|
if (d->inhibitCount == 1) {
|
|
|
|
d->compositeTimer.stop();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::uninhibit()
|
|
|
|
{
|
|
|
|
Q_ASSERT(d->inhibitCount > 0);
|
|
|
|
d->inhibitCount--;
|
|
|
|
|
|
|
|
if (d->inhibitCount == 0) {
|
|
|
|
d->maybeScheduleRepaint();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::beginFrame()
|
|
|
|
{
|
|
|
|
d->pendingRepaint = false;
|
|
|
|
d->pendingFrameCount++;
|
2020-11-28 15:12:38 +00:00
|
|
|
d->renderJournal.beginFrame();
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::endFrame()
|
|
|
|
{
|
2020-11-28 15:12:38 +00:00
|
|
|
d->renderJournal.endFrame();
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int RenderLoop::refreshRate() const
|
|
|
|
{
|
|
|
|
return d->refreshRate;
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::setRefreshRate(int refreshRate)
|
|
|
|
{
|
|
|
|
if (d->refreshRate == refreshRate) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
d->refreshRate = refreshRate;
|
2021-06-08 07:02:14 +00:00
|
|
|
Q_EMIT refreshRateChanged();
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
}
|
|
|
|
|
2021-11-04 16:34:17 +00:00
|
|
|
void RenderLoop::scheduleRepaint(Item *item)
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
{
|
2021-11-04 16:34:17 +00:00
|
|
|
if (d->pendingRepaint || (d->fullscreenItem != nullptr && item != nullptr && item != d->fullscreenItem)) {
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!d->pendingFrameCount && !d->inhibitCount) {
|
|
|
|
d->scheduleRepaint();
|
|
|
|
} else {
|
|
|
|
d->delayScheduleRepaint();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-12 21:17:21 +00:00
|
|
|
LatencyPolicy RenderLoop::latencyPolicy() const
|
|
|
|
{
|
|
|
|
return d->latencyPolicy.value_or(options->latencyPolicy());
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::setLatencyPolicy(LatencyPolicy policy)
|
|
|
|
{
|
|
|
|
d->latencyPolicy = policy;
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::resetLatencyPolicy()
|
|
|
|
{
|
|
|
|
d->latencyPolicy.reset();
|
|
|
|
}
|
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
std::chrono::nanoseconds RenderLoop::lastPresentationTimestamp() const
|
|
|
|
{
|
|
|
|
return d->lastPresentationTimestamp;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::chrono::nanoseconds RenderLoop::nextPresentationTimestamp() const
|
|
|
|
{
|
|
|
|
return d->nextPresentationTimestamp;
|
|
|
|
}
|
|
|
|
|
2021-11-04 16:34:17 +00:00
|
|
|
void RenderLoop::setFullscreenSurface(Item *surfaceItem)
|
2021-02-20 15:04:18 +00:00
|
|
|
{
|
2021-11-04 16:34:17 +00:00
|
|
|
d->fullscreenItem = surfaceItem;
|
2021-02-20 15:04:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
RenderLoop::VrrPolicy RenderLoop::vrrPolicy() const
|
|
|
|
{
|
|
|
|
return d->vrrPolicy;
|
|
|
|
}
|
|
|
|
|
|
|
|
void RenderLoop::setVrrPolicy(VrrPolicy policy)
|
|
|
|
{
|
|
|
|
d->vrrPolicy = policy;
|
|
|
|
}
|
|
|
|
|
Introduce RenderLoop
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
2020-11-19 08:52:29 +00:00
|
|
|
} // namespace KWin
|