search

awesomeWM / awesome

awesome window manager
https://awesomewm.org/
GNU General Public License v2.0
6.39k stars 597 forks source link

Use ARGB parents only for windows with ARGB #2408

Open yshui opened 6 years ago

yshui commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 months ago

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 commented 6 months ago

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.