Commit graph

10 commits

Author SHA1 Message Date
Vlad Zahorodnii
b8a70e62d5 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.
2021-01-06 16:59:29 +00:00
Vlad Zahorodnii
017528956b Move Scene::isPerScreenRenderingEnabled() to Platform
This way the Compositor can know if per screen rendering is enabled
before creating the Scene.
2020-12-02 15:32:30 +00:00
Vlad Zahorodnii
f26eeb9706 Use consistent naming for begin/end frame hooks
Currently, the OpenGLBackend and the QPainterBackend have hooks to
indicate the start and the end of compositing cycle, but in both cases,
the hooks have different names. This change fixes that inconsistency.
2020-11-12 09:14:57 +02:00
Vlad Zahorodnii
94b731c196 Prepare QPainter render backend for per screen rendering 2020-11-11 07:22:10 +00:00
Vlad Zahorodnii
edfb0a3fd9 Drop support for X11 overlay windows in QPainter render backend
It's unused.
2020-11-11 07:22:10 +00:00
Vlad Zahorodnii
4ce853e8e4 Prettify license headers 2020-08-07 19:57:56 +00:00
Vlad Zahorodnii
1fb9f6f13a Switch to SPDX license markers
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.

In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
2020-08-07 19:57:56 +00:00
Vlad Zagorodniy
5e0e708a76 Port away from deprecated QImage::byteCount
Summary:
QImage::byteCount() was deprecated in Qt 5.10. It is advised to use
QImage::sizeInBytes() method instead.

Reviewers: #kwin, apol

Reviewed By: apol

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D22355
2019-07-10 02:02:15 +03:00
David Edmundson
59515b1681 Scale QPainter x11 windowed backend
Reviewers: #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D3495
2017-03-29 20:53:22 +01:00
Martin Gräßlin
33dffc0fd7 Move the x11 plugin sources into a x11/windowed directory
Preparation step for having two x11 backends: the windowed for Wayland
and a standalone for kwin_x11.
2016-04-12 08:04:16 +02:00
Renamed from plugins/platforms/x11/scene_qpainter_x11_backend.cpp (Browse further)