kwin/src/utils/vsyncmonitor.cpp

/*
    SPDX-FileCopyrightText: 2020 Vlad Zahorodnii <vlad.zahorodnii@kde.org>

    SPDX-License-Identifier: GPL-2.0-or-later
*/

#include "utils/vsyncmonitor.h"

namespace KWin
{

VsyncMonitor::VsyncMonitor() = default;

} // namespace KWin

#include "moc_vsyncmonitor.cpp"
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`
			`*/`

Move vsync monitor helpers to utils/ There was no utils directory when they had been introduced. 2023-04-14 09:21:22 +00:00			`#include "utils/vsyncmonitor.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`
			`{`

backends: port vsync helpers to std::unique_ptr 2022-06-01 10:57:56 +00:00			`VsyncMonitor::VsyncMonitor() = default;`
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`
Add explicit moc includes to sources for moc-covered headers * speeds up incremental builds as changes to a header will not always need the full mocs_compilation.cpp for all the target's headers rebuild, while having a moc file sourced into a source file only adds minor extra costs, due to small own code and the used headers usually already covered by the source file, being for the same class/struct * seems to not slow down clean builds, due to empty mocs_compilation.cpp resulting in those quickly processed, while the minor extra cost of the sourced moc files does not outweigh that in summary. Measured times actually improved by some percent points. (ideally CMake would just skip empty mocs_compilation.cpp & its object file one day) * enables compiler to see all methods of a class in same compilation unit to do some sanity checks * potentially more inlining in general, due to more in the compilation unit * allows to keep using more forward declarations in the header, as with the moc code being sourced into the cpp file there definitions can be ensured and often are already for the needs of the normal class methods 2023-07-05 06:30:14 +00:00
			`#include "moc_vsyncmonitor.cpp"`