Skip to content
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

Use ARGB parents only for windows with ARGB #2408

Open
yshui opened this issue Sep 30, 2018 · 7 comments · May be fixed by #3910
Open

Use ARGB parents only for windows with ARGB #2408

yshui opened this issue Sep 30, 2018 · 7 comments · May be fixed by #3910

Comments

@yshui
Copy link

yshui commented Sep 30, 2018

Output of awesome --version:

awesome v4.2 (Human after all)
 • Compiled against Lua 5.3.4 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.2

awesome by default create ARGB parent windows for all windows, unless -a is specified on the command line, then ARGB is not used at all.

Probably better to use ARGB windows as needed.

@Elv13
Copy link
Member

Elv13 commented Sep 30, 2018

I think it would break exiting features such as transparent titlebars, client side shadows or generic "I have a compositor and I want to push it" cases. Also, if there is any issue, then it's wither a bug in the toolkit or the graphic driver. Yes, Awesome is one of the rare WM to do force ARGB, but it isn't a bug.

Why do you think this is an issue and how would you address the potential regressions?

@yshui
Copy link
Author

yshui commented Sep 30, 2018

Well use ARGB "as needed" means if say the titlebar is transparent, awesome should use ARGB.

Some compositors (such as compton) uses the lack of ARGB-ness of the frame window as a hint to avoid drawing over the same area multiple times.

Not meant as a bug, just thinking it's probably better to do that.

@Elv13
Copy link
Member

Elv13 commented Oct 1, 2018

Well use ARGB "as needed" means if say the titlebar is transparent, awesome should use ARGB.

Even if we added code to detect such situation (aka: add complexity), it would only cascade into more issues. One of them is what happen when you toggle titlebars visibility. Another one is what happen if you change the titlebar bg color later at runtime. Yet another would be what happen if the background is transparent, but the content is opaque.

Those corner cases would probably only be fixable by reparenting the client multiple time later during execution. This would probably cause more bugs than the ARGB surface ever causes.

Some compositors (such as compton) uses the lack of ARGB-ness of the frame window as a hint to avoid drawing over the same area multiple times.

If it only looks for that (and as far as I know it has this bug), then that's broken. RGB clients can have a shape mask with holes. Compton fails miserably to handle those properly except for the "detect rounded corner" option. In any case, it's a wild guess to apply an imperfect optimization.

@psychon
Copy link
Member

psychon commented Oct 1, 2018

Also note: Awesome is "a bit special" in that the configuration language is the (main) programming language and people can do "crazy stuff" in their config. I don't think there is an easy way for us to detect if some specific titlebar actually uses transparency or not.
Plus, a titlebar could theoretically use transparency on e.g. just every second redraw, so we'd reparent the window between a depth=32 and depth=24 on every repaint. That'd also not be nice.

(Awesome is using depth=32 windows by default since v3.5-rc1)

@yshui
Copy link
Author

yshui commented Oct 1, 2018

You've made some good points. I guess I will give up.

RGB clients can have a shape mask with holes. Compton fails miserably to handle those properly except for the "detect rounded corner" option.

This is not true though. compton handles shaped windows perfectly fine.

@yshui yshui closed this as completed Oct 1, 2018
@yshui yshui reopened this Apr 13, 2024
@yshui
Copy link
Author

yshui commented Apr 13, 2024

people can do "crazy stuff" in their config.

yeah... but current situation is suboptimal for people who don't do "crazy stuff", which would be most of us. I think there could be an option like --full-argb that enables argb for everything, and default to only use argb for argb client windows.

@yshui
Copy link
Author

yshui commented Apr 13, 2024

In fact it should be more flexible, lua code should be able to specify if it needs a argb visual when a titlebar or a drawin is created.

yshui added a commit to yshui/awesome that referenced this issue Apr 13, 2024
Don't use the same visual for all windows.

And add a --full-argb option to force ARGB visual for all windows, which
is the current default behavior.

Fixes awesomeWM#2408
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants