2014-05-23 08:11:02 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<class>CompositingForm</class>
<widget class="QWidget" name="CompositingForm">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
2019-09-25 13:49:52 +00:00
<width>526</width>
<height>395</height>
2014-05-23 08:11:02 +00:00
</rect>
</property>
<layout class="QFormLayout" name="formLayout">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
2020-03-20 09:34:08 +00:00
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
2016-07-19 15:03:58 +00:00
<item row="0" column="0" colspan="2">
<layout class="QVBoxLayout" name="verticalLayout_4">
<item>
<widget class="KMessageWidget" name="glCrashedWarning">
<property name="visible">
<bool>false</bool>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="text">
2016-07-19 15:03:58 +00:00
<string>OpenGL compositing (the default) has crashed KWin in the past.
This was most likely due to a driver bug.
If you think that you have meanwhile upgraded to a stable driver,
you can reset this protection but be aware that this might result in an immediate crash!
Alternatively, you might want to use the XRender backend instead.</string>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="wordWrap">
2016-07-19 15:03:58 +00:00
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="KMessageWidget" name="scaleWarning">
<property name="visible">
<bool>false</bool>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="text">
2016-07-19 15:03:58 +00:00
<string>Scale method "Accurate" is not supported by all hardware and can cause performance regressions and rendering artifacts.</string>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="wordWrap">
2016-07-19 15:03:58 +00:00
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="KMessageWidget" name="tearingWarning">
<property name="visible">
<bool>false</bool>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="wordWrap">
2016-07-19 15:03:58 +00:00
<bool>true</bool>
</property>
</widget>
</item>
<item>
<widget class="KMessageWidget" name="windowThumbnailWarning">
<property name="visible">
<bool>false</bool>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="text">
2016-07-19 15:03:58 +00:00
<string>Keeping the window thumbnail always interferes with the minimized state of windows. This can result in windows not suspending their work when minimized.</string>
</property>
Drop OpenGL based color correction from KWin
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
2016-11-17 14:03:54 +00:00
<property name="wordWrap">
2016-07-19 15:03:58 +00:00
<bool>true</bool>
</property>
</widget>
</item>
</layout>
</item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<item row="2" column="1">
<widget class="QCheckBox" name="kcfg_Enabled">
2014-05-23 08:11:02 +00:00
<property name="text">
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<string>Enable compositor on startup</string>
2014-05-23 08:11:02 +00:00
</property>
</widget>
</item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<item row="3" column="0">
<widget class="QLabel" name="animationSpeedLabel">
2014-05-23 08:11:02 +00:00
<property name="text">
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<string>Animation speed:</string>
2014-05-23 08:11:02 +00:00
</property>
</widget>
</item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<item row="3" column="1">
<widget class="QWidget" name="animationSpeedControls" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QVBoxLayout" name="verticalLayout">
<item>
<widget class="QSlider" name="animationDurationFactor">
<property name="minimum">
<number>0</number>
</property>
<property name="maximum">
<number>0</number>
</property>
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
<property name="tickPosition">
<enum>QSlider::TicksBelow</enum>
</property>
<property name="tickInterval">
<number>1</number>
</property>
</widget>
</item>
<item>
<layout class="QHBoxLayout" name="_3">
<item>
<widget class="QLabel" name="label_3">
<property name="text">
<string>Very slow</string>
</property>
</widget>
</item>
<item>
<spacer name="horizontalSpacer">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
<property name="sizeHint" stdset="0">
<size>
<width>40</width>
<height>20</height>
</size>
</property>
</spacer>
</item>
<item>
<widget class="QLabel" name="label">
<property name="text">
<string>Instant</string>
</property>
</widget>
</item>
</layout>
</item>
</layout>
2014-05-23 08:11:02 +00:00
</widget>
</item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<item row="5" column="0">
<widget class="QLabel" name="scaleMethodLabel">
2014-05-23 08:11:02 +00:00
<property name="text">
<string>Scale method:</string>
</property>
</widget>
</item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<item row="5" column="1">
<layout class="QHBoxLayout" name="horizontalLayout">
2014-05-23 08:11:02 +00:00
<item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<widget class="QComboBox" name="kcfg_XRenderSmoothScale">
<item>
<property name="text">
<string>Crisp</string>
</property>
</item>
<item>
<property name="text">
<string>Smooth (slower)</string>
</property>
</item>
</widget>
2014-05-23 08:11:02 +00:00
</item>
<item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<widget class="QComboBox" name="kcfg_glTextureFilter">
<item>
<property name="text">
<string>Crisp</string>
</property>
</item>
<item>
<property name="text">
<string>Smooth</string>
</property>
</item>
<item>
<property name="text">
<string>Accurate</string>
</property>
</item>
</widget>
2014-05-23 08:11:02 +00:00
</item>
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
</layout>
2014-05-23 08:11:02 +00:00
</item>
2019-09-25 13:49:52 +00:00
<item row="7" column="0" colspan="2">
2014-05-23 08:11:02 +00:00
<widget class="Line" name="line">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
</widget>
</item>
2019-09-25 13:49:52 +00:00
<item row="8" column="0">
2014-05-23 08:11:02 +00:00
<widget class="QLabel" name="label_2">
<property name="text">
<string>Rendering backend:</string>
</property>
</widget>
</item>
2019-09-25 13:49:52 +00:00
<item row="8" column="1">
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<widget class="QComboBox" name="backend"/>
2014-05-23 08:11:02 +00:00
</item>
2019-09-25 13:49:52 +00:00
<item row="9" column="0" colspan="2">
2016-07-19 15:03:58 +00:00
<widget class="Line" name="line_2">
<property name="orientation">
<enum>Qt::Horizontal</enum>
2014-05-23 08:11:02 +00:00
</property>
</widget>
</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
<item row="12" column="0">
2014-05-23 08:11:02 +00:00
<widget class="QLabel" name="label_5">
<property name="text">
<string>Tearing prevention ("vsync"):</string>
</property>
</widget>
</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
<item row="12" column="1">
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<widget class="QComboBox" name="kcfg_glPreferBufferSwap">
2014-05-23 08:11:02 +00:00
<item>
<property name="text">
<string>Automatic</string>
</property>
</item>
<item>
<property name="text">
<string>Only when cheap</string>
</property>
</item>
<item>
<property name="text">
<string>Full screen repaints</string>
</property>
</item>
<item>
<property name="text">
<string>Re-use screen content</string>
</property>
</item>
</widget>
</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
<item row="13" column="0">
2014-05-23 08:11:02 +00:00
<widget class="QLabel" name="label_6">
<property name="text">
<string>Keep window thumbnails:</string>
</property>
</widget>
</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
<item row="13" column="1">
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<widget class="QComboBox" name="kcfg_HiddenPreviews">
2014-05-23 08:11:02 +00:00
<item>
<property name="text">
2015-02-04 13:03:50 +00:00
<string>Never</string>
2014-05-23 08:11:02 +00:00
</property>
</item>
<item>
<property name="text">
<string>Only for Shown Windows</string>
</property>
</item>
<item>
<property name="text">
2015-02-04 13:03:50 +00:00
<string>Always</string>
2014-05-23 08:11:02 +00:00
</property>
</item>
</widget>
</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
<item row="15" column="1">
KCM/Compositing: Use KConfig XT in UI
Summary:
Use KConfig XT to manage most fields of the KCM.
Simplify code.
Depends on D27955
Test Plan: No functional change
Reviewers: #kwin, ervin, crossi, bport, hchain, zzag
Reviewed By: #kwin, ervin, bport, zzag
Subscribers: anthonyfieroni, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27988
2020-04-20 08:10:45 +00:00
<widget class="QCheckBox" name="kcfg_WindowsBlockCompositing">
2016-08-26 06:56:42 +00:00
<property name="toolTip">
<string>Applications can set a hint to block compositing when the window is open.
This brings performance improvements for e.g. games.
The setting can be overruled by window-specific rules.</string>
</property>
<property name="text">
<string>Allow applications to block compositing</string>
</property>
</widget>
</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
<item row="11" column="0">
<widget class="QLabel" name="latencyLabel">
<property name="text">
<string>Latency:</string>
</property>
</widget>
</item>
<item row="11" column="1">
<widget class="QComboBox" name="kcfg_LatencyPolicy">
<item>
<property name="text">
<string>Force lowest latency (may cause dropped frames)</string>
</property>
</item>
<item>
<property name="text">
<string>Prefer lower latency</string>
</property>
</item>
<item>
<property name="text">
<string>Balance of latency and smoothness</string>
</property>
</item>
<item>
<property name="text">
<string>Prefer smoother animations</string>
</property>
</item>
<item>
<property name="text">
<string>Force smoothest animations</string>
</property>
</item>
</widget>
</item>
2014-05-23 08:11:02 +00:00
</layout>
</widget>
2014-06-03 09:39:10 +00:00
<customwidgets>
<customwidget>
<class>KMessageWidget</class>
<extends>QFrame</extends>
2016-07-19 15:03:58 +00:00
<header>kmessagewidget.h</header>
2014-06-03 09:39:10 +00:00
<container>1</container>
</customwidget>
</customwidgets>
2014-05-23 08:11:02 +00:00
<resources/>
<connections/>
</ui>