After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755827 - Gnome shell dialogs cause black Screen when disabling animations
Gnome shell dialogs cause black Screen when disabling animations
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 728659 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-09-30 03:31 UTC by Weox Os
Modified: 2015-10-18 12:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
picture of bug (22.00 KB, image/png)
2015-09-30 03:31 UTC, Weox Os
  Details
shell-glsl-quad: Set a pipeline color that forces blending to be on (1.61 KB, patch)
2015-10-03 19:39 UTC, Rui Matos
none Details | Review
shell-glsl-quad: Set the pipeline blend string explicitly (1.29 KB, patch)
2015-10-05 12:55 UTC, Rui Matos
committed Details | Review

Description Weox Os 2015-09-30 03:31:31 UTC
Created attachment 312389 [details]
picture of bug

If you disable animation in gnome-shell, the gnome shell generated dialog ( not gtk dialog , the one I think you call them via clutter ) make background completely black. 

Look at attachment.

One of them is when animation is enabled (which is default and correct), but second one is from when animation is disabled.

I think this bug is important , because it ruins whole gnome experience.

Additional information : 
1.The funny thing is if you open a dialog when animation is enabled, and then disable the animation , the gnome-shell will function correctly until you restart system and login with disabled animation status.

2.I think this bug started at 3.8 , but I do not remember correctly , but I can assure you this happens in desktop with ATI graphic card (open source driver) , laptop with INTEL 4000 , another desktop with nvidia (both open source and proitory ). 

3.I have had multiple distro , debian 8 , fedora 22.all was same.

4.I even tried fedora 23. it is same .

5.I think if it is not possible to transparent when animation disabled , then just don't do it , just show gnome-shell dialog . without any transparency or blackscreen. ( I mean show it like a normal dialog , I think before 3.6 or 3.8 it was like this )

p.s. I couldn't add second attachment  but basically it shows how normal dialog is in gnome-shell
Comment 1 Weox Os 2015-10-01 02:30:20 UTC
For past 2 hours I was playing with this bug , I traced it down to radialEffect in Lightbox. 
I didn't had time to dig deeper to see we can fix Lightbox or not .
But a small and smart fix is like this : 

file : gnome-shell/js/ui/modalDialog.js

        if (!this._shellReactive) {
            this._lightbox = new Lightbox.Lightbox(this._group,
                                                   { inhibitEvents: true,
-                                                     radialEffect: true });
+                                                    radialEffect: Gtk.Settings.get_default().gtk_enable_animations });

Should I send a patch for review ? or is this enough and maintainer will fix it ?
Comment 2 Giovanni Campagna 2015-10-02 16:30:57 UTC
Mh, I can reproduce this with the power off dialog or with polkit, but not with alt-f2.
In any case, the fix is not correct, because it will cause a uniform background instead of a vignette effect without animations.
Comment 3 Weox Os 2015-10-02 16:36:41 UTC
vignette effect is feature which added in later version's (I believe it was 3.12) but this bug is ruining whole (disabled animation experience) which preposterous to say we should provide vignette (which is eye candy) or in alternative we are going to provide black screen .

I don't have time to implement vignette effect for animation disabled usage , if you don't have time , then you should disable it for animation disabled experience .

p.s. I always have this problem with gnome-3 developer. Please *UNDERSTAND* and *CONSIDER* people use gnome for work and development and production environment  , most of them use animation disabled (as far as I can see) , If you are providing eye candy for people I am okay with that but at least debug it carefully for animationless experience. 

thank you
Comment 4 Weox Os 2015-10-02 16:40:54 UTC
BTW as far as I know , all the dialog's use modelDialog.js , so basically they all call same dialog with different arguments , so if  you cannot produce it in alt-f2 I think the chances are you already opened alt-f2 dialog before disabling animation's (read bug explain , you should log with disabled animation).
but you are the gnome shell developer I am not . so consider it carefully.
Comment 5 Giovanni Campagna 2015-10-03 17:24:20 UTC
I'm sorry, I did not mean to say we should not fix this. What I meant is that the fix is incomplete, and we should investigate this further and come up with a full fix. Then again, as you point out, a black screen worse than a uniform semi-transparent one, so if the fix does not come out in time, we can definitely omit the radial effect for now.

And of course, I did not mean to imply that you should fix it, this is up to us developers. It is a reproducible bug, so I expect it would be easy to tackle.

Thanks again for the report, I hope to come back to you with a complete fix soon.
Comment 6 Rui Matos 2015-10-03 19:39:10 UTC
Created attachment 312609 [details] [review]
shell-glsl-quad: Set a pipeline color that forces blending to be on

The default pipeline color is opaque white and blending is turned
off. If we only draw with that color (e.g. because animations are
disabled and we're always drawn with opacity == 255), blending is kept
disabled since cogl_pipeline_set_color() returns early if the color
doesn't change from what was there before.

In our case we always want blending to be enabled, but, as there's no
public method to enable it, we can force it by setting the color to
something other that white while still honoring the actor opacity.

Note that the pipeline color doesn't matter since the glsl snippet we
use always sets it to black.
--

Perhaps there's a better way to force blending to be enabled but I
couldn't find one.
Comment 7 Giovanni Campagna 2015-10-03 20:19:42 UTC
Review of attachment 312609 [details] [review]:

::: src/shell-glsl-quad.c
@@ +46,2 @@
   cogl_pipeline_set_color4ub (priv->pipeline,
+                              0, 0, 0,

The new color is opaque black (from opaque white). Why does it affect blending?
Comment 8 Rui Matos 2015-10-05 12:55:12 UTC
Created attachment 312672 [details] [review]
shell-glsl-quad: Set the pipeline blend string explicitly

The default pipeline color is opaque white and blending is turned
off. If we only draw with that color (e.g. because animations are
disabled and we're always drawn with opacity == 255), blending is kept
disabled since cogl_pipeline_set_color() returns early if the color
doesn't change from what was there before.

In our case we always want blending to be enabled which we can achieve
by setting the blending string ourselves.
--

(In reply to Giovanni Campagna from comment #7)
> The new color is opaque black (from opaque white). Why does it
> affect blending?

So, I'm still not sure how exactly cogl determines how to enable
blending from the color alone but I read up a bit on blend strings and
I think I found the proper way to enable the blending we want here.
Comment 9 Rui Matos 2015-10-08 16:29:47 UTC
Jasper said 'sure' on IRC.

Attachment 312672 [details] pushed as 44047ac - shell-glsl-quad: Set the pipeline blend string explicitly
Comment 10 Weox Os 2015-10-18 06:35:33 UTC
I should thank gnome community for such fast response(especially you two).
I have one question : today I was starting virt-manager (which I believe eventually calls modalDialog for requesting permission).The background was black , do you think I should investigate this problem deeply ?
( so , be careful, I am not claiming your patch does not work,I am using old version, I am asking do you think another bug would cause such behavior? - because it was first time I am seeing this problem in animation enabled mode)
Comment 11 Rui Matos 2015-10-18 12:11:33 UTC
*** Bug 728659 has been marked as a duplicate of this bug. ***