-
Notifications
You must be signed in to change notification settings - Fork 597
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
Comments
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? |
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. |
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.
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. |
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. (Awesome is using depth=32 windows by default since v3.5-rc1) |
You've made some good points. I guess I will give up.
This is not true though. compton handles shaped windows perfectly fine. |
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 |
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. |
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
Output of
awesome --version
: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.
The text was updated successfully, but these errors were encountered: