awesome WM 3.4.* bad rendering

[r3lgar]

awesome's menu items mouse over has no hovered color and EVERY menu item has shadow, not one shadow under menu.

[richardgv]

If you have looked into how awesome-3.4.15 created those menus, funeralismatic, you will find it's awesome that caused that shit. It creates one separate window for each menu item! A quick-'n'-dirty workaround is to add --shadow-exclude 'override_redirect && _NET_WM_STRUT_PARTIAL:c' to compton's command line arguments. It removes shadow on all (possible) awesome-3.4 windows. Not the best solution, but what else could be done?

I can't reproduce the no-hovered color issue with compton (git-v0.1_beta1-14-g4bd3db2-2013-09-18) on richardgv-dev branch, with our default configuration. Tell me more about the problem, with a few screenshots and all your configuration files, if the issue is still there.

And the best fix I could see is, upgrade your awesome to 3.5.

[r3lgar]

@richardgv

http://storage5.static.itmages.com/i/13/0918/h_1379525574_5101468_8fda8df1d8.png

http://pastebin.com/pDjhSdVU

http://pastebin.com/V2SVQPjb

compton version is current, awesome 3.4.15.

[richardgv]

@funeralismatic:

I've afraid your uncooperative attitude isn't going to be helpful for resolving the problem. Your rc.lua lacks various supporting files and I had to go all around to find them. And "current" compton version isn't too great a description: compton mostly publishes as git revisions and different distros frequently provide different "current" versions, and we have two branches that could both be described as "current". The version string compton -h |& head -n1 reports is what we typically relies upon.

And just a quick note: I'm able to reproduce the issue. It happens only on XRender backend. It happens with empty compton configuration. It does not happen on Xephyr, only on a normal X. Cairo-compmgr has exactly the same issue. xcompmgr has the problem but behaves slightly differently. Forcing compton to repaint the whole screen (through D-Bus) immediately corrects the display. This may indicate an issue in xorg-server or the driver. Are you using nvidia-drivers-325.15 as well?

By the way, pinentry is not a legal window type to be placed in wintypes section of compton.conf.

[smlx]

I'm on awesome 3.4 and compton beta1, using a configuration based on the default. I can't reproduce this issue on either nouveau or radeon drivers, using either glx or xrender.

This may indicate a problem with your awesome configuration or with your driver (if you're using nvidia, intel or fglrx).

[richardgv]

After almost 5 hours of debugging... I would say, it does not look like my fault:

1. I'm using nvidia-driver-325.15, and this is the basis for all my tests.
2. The core issue here is compton doesn't receive DamageNotify when awesome-3.4.15 paints on some windows, under X Render backend. The windows that fails appear regular (i.e. a certain group of menu windows always fails to send DamageNotify). xcompmgr and cairo-compmgr behave the same.
3. compton receives DamageNotify correctly under GLX backend, and works well.
4. Once I disable RenderAccel in xorg.conf (which is a nVidia-driver specific option, and determines whether X Render gets accelerated), compton's X Render backend works correctly.
5. awesome-3.5 does not exhibit the issue, presumably because it changed the method of painting. awesome-3.4.15 uses a number of core X routines (background_pixel in X window attributes, XCopyArea(), etc.) that are already very rarely used.
6. The issue is not related to X Shape, which I once suspected.

7. This patch on awesome-3.4.15 seemingly fixes it:

   --- wibox.c~    2013-09-19 22:08:44.059965423 +0800
   +++ wibox.c 2013-09-19 22:08:45.879965419 +0800
   @@ -607,6 +607,7 @@
   {
       if(wibox->visible)
       {
   +        xcb_clear_area(globalconf.connection, FALSE, wibox->window, 0, 0, 0, 0);
           widget_render(wibox);
           wibox_refresh_pixmap(wibox);
   

   God knows why. It was stated in Xlib manual that "Changing the background does not cause the window contents to be changed. To repaint the window and its background, use XClearWindow().", but the xpyb example calls XClearArea(dpy, wid, False, 0, 0, 0, 0), so I did it...

So your possible solutions are:

1. Use compton --backend glx.
2. Apply the patch on your awesome. No idea if it would work.
3. Turn off RenderAccel in xorg.conf, if you have nvidia-drivers as well.
4. Upgrade to awesome-3.5.

@smlx:

Thanks for helping!

[r3lgar]

sorry. compton (git-v0.1_beta1-5-g4600f43-2013-08-28) from chjj's git.

nvidia 313.30.

xorg 1.14.1.

distro is Gentoo.

what files are you interested in?

[r3lgar]

Compton also paints artifacts on the root window with glx backend.

@richardgv

awesome upgrade to 3.5 is a bad idea. IMHO, awesome 3.5 has many flaws.

[richardgv]

@funeralismatic:

Update:: I forgot to mention that I still have my patch above applied on awesome-3.4.15, which may affect the issue.

what files are you interested in?

Not much now. I managed to get your configuration working (in a certain degree...) by searching for the files with Google. But next time please attach your whole ~/.config/awesome directory, other supporting files (e.g. icons), and versions of your supporting libraries (e.g. vicious).

nvidia 313.30.

Ah, so most likely the menu issue is tied with nvidia-drivers then.

Compton also paints artifacts on the root window with glx backend.

I can't reproduce it with compton-git-v0.1_beta1-14-g4bd3db2-2013-09-18, either with empty configuration or your configuration, in GLX backend. And you provided no steps to reproduce, no screenshot, no info about the appearance of artifacts, nothing, nothing, nothing.

I would suspect it has something to do with the wallpaper setter you use. You may also try flipping --paint-on-overlay, turn off --unredir-if-possible, and investigate the GLX optimization option you used, if any.