GNOME Bugzilla – Bug 755827
Gnome shell dialogs cause black Screen when disabling animations
Last modified: 2015-10-18 12:11:33 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
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 ?
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.
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
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.
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.
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.
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?
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.
Jasper said 'sure' on IRC. Attachment 312672 [details] pushed as 44047ac - shell-glsl-quad: Set the pipeline blend string explicitly
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)
*** Bug 728659 has been marked as a duplicate of this bug. ***