Cinnamon effects and visual transparency

[tsujan]

For now, my "Compiz complex" is pacified in this way:



Thanks again for the idea.

[bimsebasse]

esteban: if tsujan gets this "official" as a gnome-shell extension, and nothing happens with it in Cinnamon, then I'm gonna run down to where you're at and slap you!

tsujan: looks brilliant!

[tsujan]

esteban: if tsujan gets this "official" as a gnome-shell extension, and nothing happens with it in Cinnamon, then I'm gonna run down to where you're at and slap you!

tsujan: looks brilliant!

Thank you! And don't worry this can't be an extension. All credits go to esteban1uy

[esteban1uy]

esteban: if tsujan gets this "official" as a gnome-shell extension, and nothing happens with it in Cinnamon, then I'm gonna run down to where you're at and slap you!

I dare you!

Thank you! And don't worry this can't be an extension. All credits go to esteban1uy

That theme looks amazing!
Did you try using a "frosted glass" bumpmap with it?

[tsujan]

... That theme looks amazing!

Thank you! It's GnomishDark http://gnome-look.org/content/show.php/GnomishDark?content=147290. I'll add the Cinnamon and Nemo support to it soon.

Did you try using a "frosted glass" bumpmap with it?

As a matter of fact, I removed bumpmap and some other things to make the code as compact as possible. That's just a Gaussian blur with 5.0 as sigma. The code is promissing and I'll work on it. I've made a simple Shell/Cinnamon extension that makes all menus translucent and I'll be satisfied if blurring can be added to it too.

[esteban1uy]

As a matter of fact, I removed bumpmap and some other things to make the code as compact as possible...

Hmmm... which "commit" of the github backgrounds effects implementation are you using as a base?

[tsujan]

Hmmm... which "commit" of the github backgrounds effects implementation are you using as a base?

For now, I concentrate on Shell v3.6.2. The codes are similar and I'll surely come to Cinnamon again.

Let me tell you about my story shortly. Having used Gnome-Shell since its first version, at last I got really angry with v3.6: it was simply unusable without hacks. Then I decided to purge all traces of gnome from my system and go to KDE; enough was enough. But suddenly I discovered that Cinnamon was installable on Debian (my distro) too. I compiled and installed its latest version and began to like it so much. However, after two weeks, I found graphical bugs in it. So, now I'm temporarily back in Gnome-Shell until those bugs are fixed. I'm quite sure they'll be fixed soon.

[tsujan]

Fixing the outset shadow problem in Gnome-Shell was easier than I thought. It's enough to compensate for the shadow values with the aid of st_theme_node_get_box_shadow(), provided that st_theme_node_get_background_paint_box() is used instead of st_theme_node_get_paint_box().

Now, there only remains the border radii problem. If I solve it, I'll upload the patch for Shell.

[esteban1uy]

Now, there only remains the border radii problem. If I solve it, I'll upload the patch for Shell.

Could you please describe the problem with those rounded corners in Shell?

The problem happens only when both rounded corners and box-shadows are defined for the same widget, am I right?

[tsujan]

The problem happens only when both rounded corners and box-shadows are defined for the same widget, am I right?

No. The problem can be seen when border-radius is great enough and against some backgrounds:



Everything is OK with small border radii, even with a shadow:

[esteban1uy]

I'm sorry I wasn't able to reproduce that bug in Cinnamon:


I think you should maybe check the differences between st-theme-node-drawing.c in Shell and Cinnamon, specially the create_corner_material and the st_theme_node_prerender_background functions, because it's clear that something goes wrong with Shell's alpha management at those corners.

[tsujan]

... it's clear that something goes wrong with Shell's alpha management at those corners.

I don't think it's so serious. Perhaps it's because whenever a dialog is shown, the screens gets a bit dim and the dialog still remembers the previous state. The code can be adjusted to this. The menu borders are OK here too, although I didn't know that before.

[esteban1uy]

... it's clear that something goes wrong with Shell's alpha management at those corners.

I don't think it's so serious. Perhaps it's because whenever a dialog is shown, the screens gets a bit dim and the dialog still remembers the previous state. The code can be adjusted to this. The menu borders are OK here too, although I didn't know that before.

You're right, it maybe has to do with the dimming of the background (aka. lightbox) when modal dialogs are displayed.
Again, I wasn't able to reproduce the bug in our Cinnamon implementatio. Maybe Shell's lightbox works different than Cinnamon's:


By the way, have you changed the masking procedure in the effect's cogl pipeline snippet?
I bet you did, am I right?

[tsujan]

By the way, have you changed the masking procedure in the effect's cogl pipeline snippet?
I bet you did, am I right?

Yes, I have. But I reversed the changes without any difference. I'll let you know as soon as I fix this issue. It needs a little more free time.

[esteban1uy]

By the way, have you changed the masking procedure in the effect's cogl pipeline snippet?
I bet you did, am I right?

Yes, I have. But I reversed the changes without any difference. I'll let you know as soon as I fix this issue. It needs a little more free time.

Ok, ok, take your time. Just a little hint: instead of returning a fully transparent texel in the snippet

Code: Select all

                              "if (TransparentPixel == true) {\n"
                              "    cogl_texel = vec4(0.0);\n"
                              "} else {\n"

just define a new vec4 "dimming_color" uniform and the corresponding gobject property in the effect's source, then pass the dimming color of the lightbox to the effect in modalDialog.js, endSessionDialog.js or runDialog.js by means of that property. Then you can change the snippet to something like this:

Code: Select all

                              "if (TransparentPixel == true) {\n"
                              "    cogl_texel = dimming_color;\n"
                              "} else {\n"

... and voilà!!!

[tsujan]

This is all I found:

When the patch is adapted for use with Shell, outset shadows and most corners with big radii are distorted. Only the corners of those actors that correspond to panelmode=0 are OK.

With some changes, all shadows will be OK but none of curved corners. Your method of detecting transparent pixels doesn't work with most widgets in Shell. I removed it to have correct shadows without having highly curved corners. I couldn't find a fully working way for the detection of transparent pixels.

On the other hand, there's no hope for making the backgrounds of translucent non-Shell widgets blurred in this way.

Let's look forward to an implementation of opacity blurring in Clutter itself. It seems buggy for now, so we might have to wait a long time.

Thanks again for sharing your nice experiment

[esteban1uy]

This is all I found:

When the patch is adapted for use with Shell, outset shadows and most corners with big radii are distorted. Only the corners of those actors that correspond to panelmode=0 are OK.

With some changes, all shadows will be OK but none of curved corners. Your method of detecting transparent pixels doesn't work with most widgets in Shell. I removed it to have correct shadows without having highly curved corners. I couldn't find a fully working way for the detection of transparent pixels.

On the other hand, there's no hope for making the backgrounds of translucent non-Shell widgets blurred in this way.

Let's look forward to an implementation of opacity blurring in Clutter itself. It seems buggy for now, so we might have to wait a long time.

Thanks again for sharing your nice experiment

I'm sorry to hear it didn't work for Shell but, well... it was never meant for Shell but for Cinnamon.
The method we use to detect transparent pixels is no mistery at all: in the second pass pipeline we attach a texture with the "flattened" actor to layer 1. Then we sample that texture (using the FrontTex Sampler2D in that pipeline's Cogl snippet) and we check if the alpha value of each texel is below 0.004 (<1/256). If so, we have a fully transparent texel in layer 1 and we avoid painting the corresponding texel of the texture in layer 0 (the actual blurry background). That way the texture in layer 1 works as a "mask" for the texture in layer 0: we only paint those parts of the blurry background that corresponds with non fully transparent parts of the actor.
As for Clutter to include opacity blurring as a new effect... it seems highly improbable. Clutter already provides an API to create that kind of effects (http://developer.gnome.org/clutter/stable/ch06.html) so the answer of any Clutter developer when asked for such thing is very comprehensible: "We gave you the tools, we explained you how to use them, now do it yourself!".