| 2017-12-27 01:25:26 |
quequotion |
bug |
|
|
added bug |
| 2017-12-27 01:36:11 |
quequotion |
summary |
Black surface drawn on outward-facing sides of cube inside compiz cube |
Background drawn on outward-facing sides of cube inside compiz cube |
|
| 2017-12-27 01:37:10 |
quequotion |
description |
Something is drawing a black background on the cube that compiz cannot get rid of; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
I have seen this before, but as of yesterday there seems to be nothing that can be done about it. In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
This background does not render on the appropriate surface either, always appearing on the outward-facing surfaces of a rectangular cube regardless of what is set in Cube Reflection and Deformation.
The Wallpaper plugin does appear to be working for the Desktop Wall.
Screenshots:
https://postimg.org/image/d8lx1eyij/
https://postimg.org/image/p9phoquk5/
https://postimg.org/image/odfonf2t1/
Forum discussion:
https://bbs.archlinux.org/viewtopic.php?id=232988 |
Something is drawing a background on the cube that compiz cannot get rid of; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
I have seen this before, but as of yesterday there seems to be nothing that can be done about it. In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
This background does not render on the appropriate surface either, always appearing on the outward-facing surfaces of a rectangular cube regardless of what is set in Cube Reflection and Deformation.
The Wallpaper plugin does appear to be working for the Desktop Wall.
Screenshots:
https://postimg.org/image/d8lx1eyij/
https://postimg.org/image/p9phoquk5/
https://postimg.org/image/odfonf2t1/
Forum discussion:
https://bbs.archlinux.org/viewtopic.php?id=232988 |
|
| 2017-12-27 01:42:08 |
quequotion |
description |
Something is drawing a background on the cube that compiz cannot get rid of; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
I have seen this before, but as of yesterday there seems to be nothing that can be done about it. In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
This background does not render on the appropriate surface either, always appearing on the outward-facing surfaces of a rectangular cube regardless of what is set in Cube Reflection and Deformation.
The Wallpaper plugin does appear to be working for the Desktop Wall.
Screenshots:
https://postimg.org/image/d8lx1eyij/
https://postimg.org/image/p9phoquk5/
https://postimg.org/image/odfonf2t1/
Forum discussion:
https://bbs.archlinux.org/viewtopic.php?id=232988 |
Something is drawing a background on the cube that compiz cannot get rid of; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
I have seen this before, but as of yesterday there seems to be nothing that can be done about it. In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
This background does not render on the appropriate surface either, always appearing on the outward-facing surfaces of a rectangular cube regardless of what is set in Cube Reflection and Deformation.
The Wallpaper plugin does appear to be working for the Desktop Wall.
Screenshots:
https://postimg.org/image/d8lx1eyij/
https://postimg.org/image/p9phoquk5/
https://postimg.org/image/odfonf2t1/
Forum discussion:
https://bbs.archlinux.org/viewtopic.php?id=232988 |
|
| 2020-03-14 23:09:29 |
quequotion |
description |
Something is drawing a background on the cube that compiz cannot get rid of; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
I have seen this before, but as of yesterday there seems to be nothing that can be done about it. In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
This background does not render on the appropriate surface either, always appearing on the outward-facing surfaces of a rectangular cube regardless of what is set in Cube Reflection and Deformation.
The Wallpaper plugin does appear to be working for the Desktop Wall.
Screenshots:
https://postimg.org/image/d8lx1eyij/
https://postimg.org/image/p9phoquk5/
https://postimg.org/image/odfonf2t1/
Forum discussion:
https://bbs.archlinux.org/viewtopic.php?id=232988 |
Something is drawing a black surface on all outward-facing sides of the cube; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin. For a while, it was possible to work around this with gnome-settings-daemon-compat (which packaged gsd 3.6.1's background manager), but that has become difficult to compile since the release of libgnome 19+ (3.36.0).
I believe the cause of this may be how compiz interprets _XROOTPMAP_ID or _XROOTMAP_ID (when unset?). |
|
| 2020-03-14 23:10:17 |
quequotion |
summary |
Background drawn on outward-facing sides of cube inside compiz cube |
Black surface drawn on outward-facing sides of cube |
|
| 2020-03-14 23:12:13 |
quequotion |
description |
Something is drawing a black surface on all outward-facing sides of the cube; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin. For a while, it was possible to work around this with gnome-settings-daemon-compat (which packaged gsd 3.6.1's background manager), but that has become difficult to compile since the release of libgnome 19+ (3.36.0).
I believe the cause of this may be how compiz interprets _XROOTPMAP_ID or _XROOTMAP_ID (when unset?). |
Something is drawing a black surface on all outward-facing sides of the cube; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
For a while, it was possible to work around this with gnome-settings-daemon-compat (which packaged gsd 3.6.1's background manager), but that has become difficult to compile since the release of libgnome-desktop 19+ (3.36.0).
I believe the cause of this may be how compiz interprets _XROOTPMAP_ID or _XROOTMAP_ID (when unset?). |
|
| 2020-03-16 13:17:46 |
Alberts Muktupāvels |
bug |
|
|
added subscriber Alberts Muktupāvels |
| 2020-03-17 00:37:44 |
quequotion |
description |
Something is drawing a black surface on all outward-facing sides of the cube; even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
For a while, it was possible to work around this with gnome-settings-daemon-compat (which packaged gsd 3.6.1's background manager), but that has become difficult to compile since the release of libgnome-desktop 19+ (3.36.0).
I believe the cause of this may be how compiz interprets _XROOTPMAP_ID or _XROOTMAP_ID (when unset?). |
tl;dr: compiz should not render an empty x11 root window as a black surface; it should render _nothing_ instead.
Compiz draws a black surface on all outward-facing sides of the cube--even with cube opacity set to 0.0000 both while rotating and not rotating, and a wallpaper set by the Wallpaper plugin with no image and both colors set to 0 opacity.
In the past it was possible to restore transparency by fiddling with gnome-settings-daemon's background plugin and the dconf settings that set the background, but no state of those settings has any effect now except to change between "default black" (with the gnome-settings-daemon plugin and/or gnome-fallback-background-helper disabled) and a controllable background (can set color or image through dconf)--neither of which can be overlayed by the Wallpaper plugin.
For a while, it was possible to work around this with gnome-settings-daemon-compat (which packaged gsd 3.6.1's background manager), but that has become difficult to compile since the release of libgnome-desktop 19+ (3.36.0).
I believe the cause of this may be how compiz interprets _XROOTPMAP_ID or _XROOTMAP_ID (when unset?). |
|
