Corner Radius Fix for GLX #1261
Conversation
Update to Original Picom
|
hmmm, thanks for the patch, but i want to understand this problem better. what corner radius did you use to get these screenshots? |
|
hi @yshui , for sure! I used: and tested with corner radius 1 too and indeed looks fine with that too. |
|
hmm, i wonder if the off by 1 error is actually here: if (rect_distance > 0.0f) { // <----
c = (1.0f - clamp(rect_distance, 0.0f, 1.0f)) * rim_color;
} else {
float factor = clamp(rect_distance + border_width, 0.0f, 1.0f);
c = (1.0f - factor) * c + factor * border_color;
}maybe it should be if (rect_distance > -0.5f) { // <----
c = (0.5f - clamp(rect_distance, -0.5f, 0.5f)) * rim_color;
} else {
float factor = clamp(rect_distance + border_width, 0.0f, 1.0f);
c = (1.0f - factor) * c + factor * border_color;
}? |
|
Hmmm, I tried that change but it makes shadows disappear, ok, not disappear but to see them I need to set shadow-opacity to 0.9 or so, so it affects the shadow in big way. The -1 I added doesn't seem to affect the shadow at all. |
|
So my current thought is this: |
This adds support for desktop switching animations by keeping track of _NET_CURRENT_DESKTOP atom on the root window. As far as I understand this atom is set by window managers and so if it changes we can know that it's a desktop switch happening. Unfortunately window manager may need to set this BEFORE hiding/showing windows so we can animate correctly, me personally using FluxBox and this quick change pijulius/fluxbox@83ee4db makes it work just fine. It adds the following animation triggers: * workspace-out * workspace-out-inverse * workspace-in * workspace-in-inverse Unfortunately had to add inverse variables too as you may navigate to the next workspace from for e.g. 1st to 2nd but you may also go to 2nd from 1st and in that case the animations have to be totally different. Here is a config example for switching workspace: animations = ({ triggers = ["workspace-out"]; offset-y = { timing = "0.2s cubic-bezier(0.21, 0.02, 0.76, 0.36)"; start = "0"; end = "-window-height"; }; shadow-offset-y = "offset-y"; opacity = { timing = "0.2s linear"; start = "window-raw-opacity-before"; end = "window-raw-opacity"; }; blur-opacity = "opacity"; shadow-opacity = "opacity"; }, { triggers = ["workspace-out-inverse"]; offset-y = { timing = "0.2s cubic-bezier(0.21, 0.02, 0.76, 0.36)"; start = "0"; end = "window-height + window-y"; }; shadow-offset-y = "offset-y"; opacity = { timing = "0.2s linear"; start = "window-raw-opacity-before"; end = "window-raw-opacity"; }; blur-opacity = "opacity"; shadow-opacity = "opacity"; }, { triggers = ["workspace-in"]; offset-y = { timing = "0.2s cubic-bezier(0.24, 0.64, 0.79, 0.98)"; start = "window-height + window-y"; end = "0"; }; shadow-offset-y = "offset-y"; opacity = { timing = "0.2s linear"; start = "0"; end = "window-raw-opacity"; }; blur-opacity = "opacity"; shadow-opacity = "opacity"; }, { triggers = ["workspace-in-inverse"]; offset-y = { timing = "0.2s cubic-bezier(0.24, 0.64, 0.79, 0.98)"; start = "-window-height"; end = "0"; }; shadow-offset-y = "offset-y"; opacity = { timing = "0.2s linear"; start = "0"; end = "window-raw-opacity"; }; blur-opacity = "opacity"; shadow-opacity = "opacity"; })
This adds the possibility to define the frame opacity but also include all colors in the window that match the frame color and make those also transparent. It even supports the possibility to define the tolerance for color difference between the frame and other parts of the window and make those or gradually more opaque or also transparent just like the frame. NOTE: tested with flat window frame so not sure how it will work with gradient frames and also only added for GLX atm, lets see if it's interesting enough to be included in the core or otherwise will just keep it for myself. It adds the following config options: # Enable frame opacity for colors that match the frame frame-opacity-for-same-colors = true; # Tolerance for similar colors (0 exact match, 1 all colors, default 0.5) frame-opacity-for-same-colors-constraint = 0.5; # Make different colors opaque by a factor of x (default 5) frame-opacity-for-same-colors-multiplier = 5; and for them to work you will have to active frame opacity for e.g. frame-opacity = 0.7; With these options you can now have blurred transparent frame + menubar + toolbar or on popup like File Open have transparent window background but list of files be opaque and so on.
|
FYI: have now fixed rounded corners for the mask too, please see: Also added this new feature:
not sure what you think about it, if you like it at all can work on formatting and other backends too but for now to showcase and for myself this was enough to achieve what I wanted. |
Tried to come up with better way to get the color of the frame and if I understood texelFetch correctly it should gather the correct pixel now and even exclude the border in case your windows have some.
|
Are we likely to see this, or something like it land in master at some point @yshui? |
|
@frebib, if you're looking for smoother rounded corners you can also try my squircles branch, see #609 (comment) (no eta of landing in the next branch, i guess it has some demand but there are open questions about how it should be implemented in production and missing implementation for the xrender backend). |
|
Yes, I want to have this fixed in |
|
@pijulius hi, can you rebase your branch on top of |
|
hi @yshui not sure what you mean by that, I have updated my repo to the next and all my changes are now up to date with your repo. If there is something I need to change please let me know and will get onto it asap. Please note, there are only 3 main changes in my repo:
Please feel free to use any of these in the core as you wish, I don't mind if you don't pull but add the changes you find useful manually as the only thing that is important is the end result :) |
|
@pijulius hi, you updated your branch by merging |
Closes #1261 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Co-authored-by: Istvan Petres <pijulius@users.noreply.github.com>
|
hi @yshui not sure what you did as I see you added the corner radius fix of your own but unfortunately there are some problems:
Please note: this is all using current next brunch directly from your repo and using the picom.sample.conf from it too so no modifications at all nor any custom config settings. Also tested my fork of your repo and that works just fine with the above tests cases (using your own picom.sample.conf and changing as noted above) so it must be something within the latest 14 commits: |
|
have tracked it down to these changes: if you undo these changes everything seems to be working just fine. |
|
hi @yshui It only adds two small numbers, nothing more, just two -1 and that's it and that makes it work in any situation without having to add any special case for 0 or non zero values and it also matches xrender corner radius too. Your latest fix here: brakes again other things, please see attached screenshots and also as you can see it doesn't make the bottom borders any different at all.
This small popup window showing the position showcases the additional border around borderless windows Really hope you reconsider. |
Fixes #1311 Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
because it's technically wrong to subtract from |
|
@pijulius try https://github.com/yshui/picom/tree/rounded-corner-anti-alias, i think this is the best option i can come up with. |
@yshui this is looking good! thank you! ps: "since that moves the center of the circle." exactly what was trying to achieve :) |
This should fix the corner radius in the glx backend to be almost exactly the same as xrender.
Not that good at math myself but I think the problem lies behind the circle already being the right size just the center of it was positioned off a bit and that's why it looked a bit "rectanglish".
Please see attached screenshots.
