-
-
Notifications
You must be signed in to change notification settings - Fork 596
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
Border color estimation doesn't work well with multiple layers of borders #1031
Comments
possibly related #285, i'll take a detailed look at your issue a bit later |
how is your terminal transparent without a compositor?.. what's the behavior without a configuration file ( |
do i understand correctly that the only issue with messed colors is windows' borders? ah, |
can you track down the issue to a particular option? or, maybe, a combination of options. i suspect it may be the |
I was able to narrow it down. Disabling corner-radius and nothing else normalizes the window frames, so the issue is specifically with corner-radius it seems. |
hm, i was working with rounded corners a few days ago (i didn’t break it, i swear!) and there is a mechanism that detects borders (width and color) and rounds them as well. looking at your screenshots: do you have double borders set up? |
In HerbstluftWM there are layers of borders. HLWM distinguishes between frames (ie containers on the screen for several windows) and the windows themselves. I have all frame borders disabled. For windows I believe I have 3 enabled on all the windows. Border (a “container” border for the other 2), an inner border, and an outer border. Inner border draws from the inner edge of the container border out, and outer border draws from the outer edge of the container border in. Neither can surpass the boundaries of the container border and all 3 have their own colors. The color of borders shifts between active and inactive windows. I believe inactive windows don’t have outer borders enabled. |
Edit: the inactive windows don’t have inner borders enabled, and both active and inactive windows share the same parameters for the container border |
Just a wild guess, but if memory serves me correctly, the glx backend gets one of the border pixels as the border color (which is different to the xrender backend) for drawing the rounded overlay part. If you use a bevel effect with three different border colors it might only use the outermost color to draw the whole border... |
@Nidkid, i believe that if you configure your wm to have a single border (the "container" you mentioned above), i.e. yellowish for active windows and black for inactive windows, the |
Alright, I just checked and it does work in the way you described. Changing the color of the outermost ring affects the whole border, so removing the thin strip of dark blue around the yellow allowed the whole border to become yellow. Ideally though, I would eventually want to utilize the layers provided to me by my window manager for a cleaner framing effect. |
Platform
Artix Linux
GPU, drivers, and screen setup
Asus Vivobook Laptop, built in screen
CPU: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8) @ 2.100GHz
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series
I have mesa and vulkan drivers installed.
Environment
Herbstluftwm window manager
picom version
Diagnostics
Extensions:
Misc:
(Another compositor is already running)
Drivers (inaccurate):
AMDGPU, Radeon
Backend: glx
Backend: egl
Expected behavior
Herbstluftwm's Window Frame colors remain consistent between No Compositor, GLX and Xrender
Current Behavior
no compositor

xrender

glx

No Compositor, Xrender retain the same window frame colors but GLX changes them entirely.
OpenGL trace
uploaded the apitrace to another site because it was 4mb long (upload will expire in 30 days from 03/09/23)
I only traced the GLX version.
https://easyupload.io/l5gjdp
The text was updated successfully, but these errors were encountered: