Improve performace of the shadow clipping code

As a comment here, I think what we'll /try/ to do is implement shadow paint layers, since the clipping code is not exactly ... performant (but a start).

I'm not really sure here, whether its appropriate to actually have shadows generated by compiz itself and essentially retire the shadow generation in libdecoration .... There's the obvious problem here with nonrectangular windows and decorations and trying to clip the shadows off and render them elsewhere ...

Paint layers sounds good. Don't be afraid of overdraw (instead of clipping) because that's what allows high-performance rendering in games etc.

I have been thinking a "shadow" plugin would be the most elegant solution;
1. Start with a simple implementation that just renders a grey rectangle before rendering each window.
2. Get the stacking order right -- draw window and shadow layers back-to-front.
3. Implement smooth gradients (Gaussian?).

I would expect some fixes required in core here and there, but mostly shadows can be the sole job of a new plugin.

Also, a simple implementation does not even need to pay attention to the decorations. If you have broad and smooth shadows you can put them under any window and it will look right for just about any decoration size/shape anyway.

On Tue, 14 Feb 2012, Daniel van Vugt wrote:

> Paint layers sounds good. Don't be afraid of overdraw (instead of
> clipping) because that's what allows high-performance rendering in games
> etc.
>
> I have been thinking a "shadow" plugin would be the most elegant solution;
> 1. Start with a simple implementation that just renders a grey rectangle before rendering each window.

You would have to clip out the grey rectangle.

> 2. Get the stacking order right -- draw window and shadow layers back-to-front.
> 3. Implement smooth gradients (Gaussian?).
>
> I would expect some fixes required in core here and there, but mostly
> shadows can be the sole job of a new plugin.
>

Well, we can't add plugins at this point because of the problems
encountered at changing the user's configuration plus its after FF.

I think what we can do for now is, draw the shadow using the clip region
created by outputRect n inputRect on one layer and then draw the window
/with/ a clipped shadow using inputRect as the clip region (transformed
using glDrawGeometry.

wdyt?

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/931883
>
> Title:
> Improve performace of the shadow clipping code
>
> Status in Compiz Core:
> Confirmed
>
> Bug description:
> This branch is a starter lp:~smspillaz/compiz-core/compiz-
> core.fix_slow_movement
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/931883/+subscriptions
>

What I'm trying to say is that it would be very easy (in theory) to make a shadow plugin that doesn't have any of the drawbacks of the current decor shadowing. And the code could potentially be quite small.

On Tue, 14 Feb 2012, Daniel van Vugt wrote:

> Also, a simple implementation does not even need to pay attention to the
> decorations. If you have broad and smooth shadows you can put them under
> any window and it will look right for just about any decoration
> size/shape anyway.
>

I agree - you can do this easily using a simple shader (paint window, make
all nonalpha pixels black, hpass, vpass, save result until window
resized), but not for this cycle :)

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/931883
>
> Title:
> Improve performace of the shadow clipping code
>
> Status in Compiz Core:
> Confirmed
>
> Bug description:
> This branch is a starter lp:~smspillaz/compiz-core/compiz-
> core.fix_slow_movement
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/931883/+subscriptions
>

I don't think we're on the same page yet. But no matter -- I was talking distant future and you're rightfully more concerned with the present.

On Tue, 14 Feb 2012, Daniel van Vugt wrote:

> What I'm trying to say is that it would be very easy (in theory) to make
> a shadow plugin that doesn't have any of the drawbacks of the current
> decor shadowing. And the code could potentially be quite small.
>

Yes, I agree entirely, it would be very simple. But it will count as a new
"feature" so we can't do it like that :)

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/931883
>
> Title:
> Improve performace of the shadow clipping code
>
> Status in Compiz Core:
> Confirmed
>
> Bug description:
> This branch is a starter lp:~smspillaz/compiz-core/compiz-
> core.fix_slow_movement
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/931883/+subscriptions
>

On Tue, 14 Feb 2012, Daniel van Vugt wrote:

> What I'm trying to say is that it would be very easy (in theory) to make
> a shadow plugin that doesn't have any of the drawbacks of the current
> decor shadowing. And the code could potentially be quite small.
>

Another thought - if we wanted to do this the best way would be to add a
new option to the decor plugin for "dynamic shadowing" which would use the
shader + fbo trick that I mentioned earlier. Then that option would tell
the decor plugin to tell the decorators to not generate any shadows (they
read the options directly from an xprop we set).

Cheers,

Sam

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/931883
>
> Title:
> Improve performace of the shadow clipping code
>
> Status in Compiz Core:
> Confirmed
>
> Bug description:
> This branch is a starter lp:~smspillaz/compiz-core/compiz-
> core.fix_slow_movement
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/931883/+subscriptions
>

I'm not sure what shaders or FBO's have to do with this. The simplest and fastest implementation would be plain old OpenGL 1.x rendering a rectangle (and later rendering 4 x textures). Nothing more is required.

Let's not make the Unity mistake of getting deep in shader and FBO magic that could actually be achieved with much simpler OpenGL code (no shaders or FBO extensions).

On Tue, 14 Feb 2012, Daniel van Vugt wrote:

> I'm not sure what shaders or FBO's have to do with this. The simplest
> and fastest implementation would be plain old OpenGL 1.x rendering a
> rectangle (and later rendering 4 x textures). Nothing more is required.
>
> Let's not make the Unity mistake of getting deep in shader and FBO magic
> that could actually be achieved with much simpler OpenGL code (no
> shaders or FBO extensions).
>

Probably for rectangular windows there's a much faster codepath that can
be used here, which is like you said, just 5x textures (4 corners, 1 for
each of the sides).

On the implementation detail end of things, using shaders and fbos is
not really as heavy as one may think - for each window of the
same shape you only need to render one. The fbos only need to be bound
every time the shadow itself is rendered, not every time it is blitted
(which is an important distinction to make).

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/931883
>
> Title:
> Improve performace of the shadow clipping code
>
> Status in Compiz Core:
> Confirmed
>
> Bug description:
> This branch is a starter lp:~smspillaz/compiz-core/compiz-
> core.fix_slow_movement
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/931883/+subscriptions
>

This bug was fixed in the package compiz - 1:0.9.7.6-0ubuntu1

---------------
compiz (1:0.9.7.6-0ubuntu1) precise; urgency=low

  [ Didier Roche ]
  * New upstream release:
    - Memory leak in dlloaderListPlugins (LP: #968985)
    - priv->invisible is not updated when the window is mapped (LP: #969102)
    - window management, multi-monitor - In multi-monitor environment, windows
      should spread on the monitor in which they reside (LP: #919139)
    - Drop-down menus look disembodied from their titles (LP: #659816)
    - Improve performace of the shadow clipping code (LP: #931883)
    - DecorWindow::computeShadowRegion called way too much (LP: #969101)
    - white box randomly shows up at top left corner blocking application
      from using stuff under it (LP: #940603)
  * Rebuild against latest metacity to get the HUD key configuration
    exposed in unity 3D as well (LP: #969256)
  * debian/patches/ubuntu-config.patch:
    - set multioutput_mode to all outputs (windows to be scaled on each the
      monitor they are on only) (LP: #919139)
  * debian/patches/fix_976467.patch:
    - Fix shadows being clipped incorrectly (LP: #976467)

  [ Oliver Grawert ]
  * update the GLES2 patch for the new upstream release.
 -- Didier Roche <email address hidden> Wed, 11 Apr 2012 18:35:39 +0200