-
-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dual-kawase blur algorithm for new OpenGL backend #382
Conversation
Codecov Report
@@ Coverage Diff @@
## next #382 +/- ##
==========================================
- Coverage 37.46% 36.54% -0.93%
==========================================
Files 45 45
Lines 8671 8896 +225
==========================================
+ Hits 3249 3251 +2
- Misses 5422 5645 +223
|
Hey guys, little bit off topic, but idea! I just got into tiling window managers and wouldnt survive without your fork. I was wondering if it is possible (maybe I missed something even after hours of searching) to have blur set up to be across all windows, but then increase the blur strength on the focused window, just an idea that I feel would cap my theme! Thanks! |
@Shadorain having different strength-levels similar to active/inactive opacity should be possible with a second set of parameters. But then you could also request per-window rules of blur-strength... I think it should be priority to get blur-algo in general merged first. 😉 Keep in mind, that strength-fading with this algorithm requires some hackery and will never be smooth due to the discrete nature of the internal sample-iterations. See #32 (comment) for an explanation and tryone144/compton#2 for some hacked samples. |
to be honest, I'm not sure what I did to make it this way, but when i remade my entire configuration file by hand just now, somehow (not even trying) I was able to get a very strange effect that I'm not too sure if its a bug or not Thank you for the quick reply! I will see what i can do about your comment too, how i can implement it |
hey, @yshui, since the pull request is here (though it still requires some work, but i don't think there is much to do), may i ask you: are you planning to merge it before releasing v8? would be amazing to have dual kawase blur in v8 (and, hopefully, rounded corners in v9) :) |
I wouldn't want to rush things, especially in light of #385. Should be fine with releasing v8 first and then add these visual features in v9. Except for the small changes outlined above, this code should be feature complete and seems to run without issues. The thing I am currently kinda stuck on is how to handle #349 as these changes have some implications on the rendering logic. Edit: Well, I'm a bit slow. v8 is already out... 😆 |
This is to be expected and due to the way windows are rendered. Each window is rendered one by one and the current result is used for blur calculation (i.e. the top-most window includes the already rendered windows below into its calculations as one would expect). It would be possible to only take the pixel directly below the window into account for bluring, but this will introduce artifacts when pixels directly at the window border change — mostly noticable when moving a floating window. See this comment for a more in-depth explanation. This should however be fixable by something like #265, although the implementation in 6a3d135 seems to clip to little leading to artifacts on the edge of the windows as there are still parts of the underlying window sampled. This is a different issue though and has to be fixed separately. |
@tryone144 The clipping added in #265 clips the window directly under the transparent window's body, so it's expected to have windows around the transparent window included in the blur. I agree it's not pretty. We could probably use Edit: This would require a change of the backend interface. So let's merge dual-kawase first. |
This sounds like a good solution. Actually, that's exactly what I thought you would implement when I read the posts. 😆 |
Another idea I just had regarding this issue should still allow visual overlapping of windows. I guess currently the sorting of the windows is done by the window manager, and in this order the windows are drawn by the compositor. Resort the window draw order, allowing multiple windows drawn at once / with the same background framebuffer based on how they're overlapping (maintaining the original order). This could possibly also solve problems with shadows overlapping neighboring windows (I'm pretty sure it's the same issue) |
<rant> Extending the |
yeah, i had this problem with all tooltip menus initially, but i was too lazy to dig in, so i just set not sure what you meant with "extending the
if we are going for this, would be good to implement this in a separate pull request as well and merge before this pull request. |
Exactly this. 😆 |
209d9b6
to
9b4a6f0
Compare
Applied the changes discussed above and squashed some unnecessary commits.
Done.
Will take a look into this next and then rebase on top of that PR. |
Also segfaults when closing a window sometimes. My config
|
This issue is not directly related to this PR and happens on |
Perhaps the same crash as #390? |
9b4a6f0
to
72990cb
Compare
72990cb
to
21ab70d
Compare
Running flawlessly on my setup since the last rebase (apart from the unrelated assertion failures in the experimental backends) and I haven't gotten any complaints, so it seems to be good for merging. If there is enough demand, I can try to cleanly backport the dual_kawase code to the legacy backend as well. |
I will try to review this ASAP. P.S. @tryone144, may I interest you in becoming a collaborator of the picom project? (In other words, can you help me review PRs, handle issue and maybe fix bugs for picom, please?) |
I'll gladly help out with handling issues and PRs. 😄 |
@tryone144 It's still better than just having me. Basically I am going to add you as a collaborator on this project, so you will be able to push to this repository, create new branches here, and approve pull requests. Although you will be able to push directly to the |
Sounds good to me. :) |
acf6935
to
b698735
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still going through the last commit.
A small nit.
LGTM, only found some nits. |
Support an arbitrary number of auxiliary textures and framebuffers for blur. Preparation for the dual-filter kawase algorithm.
**Work-in-Progress** Add `dual_kawase` to configuration and argument parsing. Allow `kawase` for backward compatibility. Add `--blur-strength` parameter for blur-method `dual_kawase`. Update documentation to reflect the new blur-method and parameters.
**Work-in-Progress** Generate suitable parameters for dual-filter kawase blur based on the selected `blur-strength` or approximate a gauss blur with the selected `blur-size` and std-deviation.
…e [WIP] **Work-in-Progress** Split-off kernel-blur specific initialization and rendering from common OpenGL setup. Add stub functions for dual_kawase-blur initialization and rendering.
Implement the dual-filter kawase blur algorithm for the new OpenGL backend as seen in kwin [1]. Use with `--blur-method dual_kawase` and set the desired strength with `--blur-strength level` (1-20). The dual-filter kawase algorithm produces results close to a traditional gaussian blur with higher performace, especially at high blur radii. The supported strength levels provide an effect similar to gauss-radii between 4 and 500 pixels. As this algorithm relies heavily on the texture-filtering units of a GPU, there is no support for the xrender backend — at least for now. [1](https://kwin.kde.narkive.com/aSqRYYw7/d9848-updated-the-blur-method-to-use-the-more-efficient-dual-kawase-blur-algorithm)
b698735
to
5e0215a
Compare
We can finally merge this after so long. Feels like there needs to be some celebration of some sort. |
Also, huge thanks to @tryone144 for their amazing work, patience and perseverance. |
Replaced picom with its experimental version from the AUR, which adds the dual-filter kawase blur algorithm for background blurring. PR: yshui/picom#382 When this gets merged into the stable version, I might reinstall the stable version again, though the experimental version was just as stable for me.
This PR implements the dual-filter kawase blur algorithm as found in KWin.
Usable with
--blur-method dual_kawase --blur-strength 7
.This is currently work-in-progress and open for comments. DO NOT MERGE.Should be ready to merge now.
Previous discussion: #32
See also: #361
EDIT: Sorry, clicked submit too fast...