Bug 431068 - FR: Disabling the blur effect for non-visible parts of the windows
Summary: FR: Disabling the blur effect for non-visible parts of the windows
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-02 14:32 UTC by ParsaMousavi
Modified: 2021-02-01 04:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
sepamou: Usability+
sepamou: Decision-Required+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ParsaMousavi 2021-01-02 14:32:11 UTC
I'm a fan of nice desktop effects like blur.But the performance of the KWin's blur plugin is terrible.It's slow on low-end systems and consumes a lot of power on high-end systems with high-res displays.

I know there have been a lot of optimizations and many bug fixes over the past few years but the compositor still lacks an important feature:
If someone stacks e.g 10 transparent windows on top of each other,then KWin has to update the background blur of all of them once a small change appears on the screen(Even if they're not visible,e.g a completely opaque window covers some translucent windows).

If it eliminates the transparency of non-focused windows,then the effect would be sometimes useless(Windows10 does this,but the use of the blur effect in Win10 is much less widespread compared to the widget themes we use in KDE like Kvantum or QtCurve or even Aurora themes).

I'm thinking of a way to disable the blur effect for parts of the non-focused windows which are covered,and just leave them simply transparent.This of course doesn't need any change to the widget toolkits like Qt,but makes kwin less resource-hungry.

What's your opinion as the KWin developers and what do you think about the possible performance gain?
Comment 1 David Edmundson 2021-01-02 15:02:15 UTC
>What's your opinion as the KWin developers and what do you think about the possible performance gain?

If you change the word "focus" to stacking order, it seems a viable option that will probably look close-enough. 

Though note that it is one of many possible ways to improve blur performance.

With my plasma hat on, given our default themes deliberately don't blur, it isn't something I would prioritise. 

Ultimately it's not really a bug, but a specific technical suggestion. If we're going to make a very technical suggestion, it's best communicated with a patch and benchmarks.
Comment 2 Bug Janitor Service 2021-01-17 04:33:17 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Bug Janitor Service 2021-02-01 04:33:17 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!