luisbocanegra / plasma-panel-colorizer

Latte-Dock and WM status bar customization features for the default KDE Plasma panel
https://store.kde.org/p/2130967
GNU General Public License v3.0
237 stars 3 forks source link

Edges of widget backgrounds with radius 0 and no padding have small seams and corners #64

Open AlexFolland opened 3 months ago

AlexFolland commented 3 months ago

I have panel background hidden, padding set to 0, and widget background enabled, except for the spacer. This is so that I can see part of my desktop background (or any full-screen program) in the unused space. That all works, but there are these thin seams which are especially visible in the corners of the widgets. Here's a screenshot.

image

Just to clarify, the expected behavior is to have no seams and square corners so that the fact that there's a background on each widget instead of the overall panel is not visible.

luisbocanegra commented 3 months ago

The small thing in the corners looks like a glitch, does it show all the time?

If I understood you correctly you want to achieve something like this?

Screenshot_20240812_182114

This preset does exactly that for me issue64panelColorizerConfig.txt

Can you save and share yours then try the one above? Presets are saved in ~/.config/panel-colorizer/

One thing to note is that (as stated in the settings) forcing a fixed side padding is somewhat buggy so achieving this look in a panel that doesn't fill the height/width of the screen is not possible right now, hopefully I will find a solution for that when I get around doing the rewrite.

AlexFolland commented 3 months ago

In fact, you can see the issue in your screenshot. You're using a dark background so it's harder to see, but if you put a lighter background on, you can see it just below the KDE icon and also just above the clock. Here's a picture of the issue in a zoomed-in image of your screenshot. Sorry it's blurry, but KDE Plasma doesn't switch to nearest-neighbor scaling when it zooms in like XFCE does. I need to report that to KDE devs.

image

Looks like we have a similar configuration and both have the issue. It's just particularly easy to see in my setup because I had a very bright background and absolutely black widget backgrounds.

luisbocanegra commented 3 months ago

Okay, I see it on my screen now, not sure how I didn't notice before as I use bright wallpapers sometimes.

This seems to be a rendering problem related to Kirigami's ShadowedRectangle (https://github.com/KDE/kirigami/blob/master/src/primitives/shadowedrectangle.cpp) which is what I use to draw the widget/panel background with shadows and rounded corners.

Wrote two small examples to simulate the panel and the Kirigami ShadowedRectangle type has this problem while the regular rectangle doesn't.

Setting the border width to -1 makes the glitch go away (or at least I don't see it with my monitor/eyes), maybe there's some miscalculation somewhere related to the borders???

Screenshot_20240812_213742

import QtQuick
import QtQuick.Layouts
import org.kde.kirigami as Kirigami

Rectangle {
    width: 300; height: 200

    property color bgColor: "#ffffff"
    property color rectColor: "#323232"

    Rectangle {
        color: bgColor
        anchors.fill: parent
        ColumnLayout {
            anchors.fill: parent
            Text {
                text: "Kirigami.ShadowedRectangle"
            }
            GridLayout {
                height: 40
                width: parent.width
                columnSpacing: 0
                Repeater {
                    model: 6
                    delegate: Kirigami.ShadowedRectangle {
                        id: kirigamiShadowedRectangle
                        Layout.preferredHeight: parent.height
                        Layout.fillWidth: true
                        color: rectColor
                        border {
                            width: 0
                            color: "white"
                        }
                    }
                }
            }

            Text {
                text: "Kirigami.ShadowedRectangle border: -1"
            }
            GridLayout {
                height: 40
                width: parent.width
                columnSpacing: 0
                Repeater {
                    model: 6
                    delegate: Kirigami.ShadowedRectangle {
                        id: kirigamiShadowedRectangle
                        Layout.preferredHeight: parent.height
                        Layout.fillWidth: true
                        color: rectColor
                        border {
                            width: -1
                            color: "white"
                        }
                    }
                }
            }

            Text {
                text: "Rectangle"
            }
            GridLayout {
                height: 40
                width: parent.width
                columnSpacing: 0
                Repeater {
                    model: 6
                    delegate: Rectangle {
                        id: qtRectangle
                        Layout.preferredHeight: parent.height
                        Layout.fillWidth: true
                        color: rectColor
                    }
                }
            }
        }
    }
}
AlexFolland commented 3 months ago

This kind of positional texture issue is common with graphics programming because there are many programmers who don't know the positioning of what's called "texels" in relation to screen pixels in modern graphics APIs. The edge points on these texels are actually in the middle of pixels, so if whole numbers are used instead of offsetting those whole numbers by 0.5 for mapping the texels, the texel squares don't accurately match the positions of the pixels, and so the edges end up being rasterized as half the neighboring color. The following article demonstrates the issue and explains what I'm talking about visually, at least in relation to Direct3D 9: Directly Mapping Texels To Pixels (Direct3D 9).

I'm actually just guessing it's similar with OpenGL and Vulkan, or whatever is being used in this case in KDE Plasma Wayland. I've seen similar issues many times in many places and I'm guessing it's because so few programmers understand this (and even I was lucky to stumble across that article back in 2011 when trying to help the RetroArch devs with the D3D9 renderer for Windows).

Regardless of what is actually causing the issue, thanks for acknowledging the issue.

AlexFolland commented 3 months ago

By the way, I tried to set border ("Outline" in the Panel Colorizer Widget background settings) width to -1, but that edit box rejects negative number input, so I can't use the workaround you mentioned for now.

AlexFolland commented 3 months ago

Setting a widget outline width of 1 with the same color as the widget background (custom color black, in my case) and full opacity (1.00) does work around the issue. I'll be using that workaround for now then.

luisbocanegra commented 2 months ago

Reopening because the hack of setting the border to -1 wasn't a very good idea as it causes some other sizing issues.

AlexFolland commented 2 months ago

Did github just re-close this with the same commit from before?

luisbocanegra commented 2 months ago

My bad, reopening.

AlexFolland commented 1 month ago

I think this was incorrectly auto-closed by the reverted commit again, this time as part of a release message.

luisbocanegra commented 1 month ago

oops