https://bugs.kde.org/show_bug.cgi?id=480376
Bug ID: 480376
Summary: Bring Back Compositing Setting
Classification: Plasma
Product: kwin
Version: 5.27.10
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: compositing
Assignee: kwin-bugs-n...@kde.org
Reporter: nroycea+...@gmail.com
Target Milestone: ---
SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug
symbols.
See
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***
Due to a previous bug (linked below), I found that compositing was disabled on
my system (the cause for that linked issue), but there was no setting available
in the GUI to change such feature.
I was forced to use QDBus to manually find it under KWin and re-enable it.
STEPS TO REPRODUCE
1. Magically disable compositing (via some dbus app, or an older KDE version
that had the compositing setting)
2. Try to use todays KDE's "Settings" to re-enable it.
OBSERVED RESULT
Compositing setting was removed quite some time ago
EXPECTED RESULT
The return of the compositing setting
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma: Arch Linux
(available in About System)
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
ADDITIONAL INFORMATION
Ref: https://bugs.kde.org/show_bug.cgi?id=470998#c7
If I recall correctly, the setting allowed you to switch between
disabled/X11/OpenGl. But for whatever reason, that option no longer exists.
I know I've disabled it in the past (when the setting was available in
Settings) because of rendering issues (not seen yet after re-enabling, but even
now I'll have performance responsiveness issues).
It's on a very old Gen7 Haswell with 8GB RAM (was waiting for Alder Lake, then
Meteor Lake looked better, but not going to happen, so sight is set on Arrow
Lake now).
As an aside which can be ignored since I see it's expressed elsewhere many
times over, I too don't care for the 5.27 tiling that was produced, where it
locks windows-sizes to each other. That must change by becoming an option.
My ideal is to have 25%-corner snapping, and even top-max snapping and
side-edge snapping (as it all was before), but not to have any snapped window
latch onto any other window edge when it is being resized. I can see the value
for some, but when it's indiscriminate to which window(s) it latches onto, I
see that as a problem.
Even now when I start off with 1/4-snapping, which works out fine, then start
doing other odd snapped window sizes (resized; non-1/4), any re-1/4-snapping
now starts going off of where that oddly-snapped window is (or even "was",
after that window was closed).
Like I said, this rant can be ignored since it's all been said ad nauseam in
other places and must already be on the dev's radar. It's only mildly related
(via the linked reference).
--
You are receiving this mail because:
You are watching all bug changes.
