plasma and new shadow mess

[Martin Gräßlin]

Am 07.01.2013 14:18, schrieb Aaron J. Seigo:
> On Monday, January 7, 2013 11:14:49 Martin Gräßlin wrote:
>> The shadow system has been designed to work around the problem which 
>> occurs
>> if we try to have the shadow in the panel. That is for any window 
>> where the
>> shadow should not be part of the window geometry. It makes sense for 
>> the
>> panel, for KRunner and the Oxygen menus.
>
> it also matters for tooltips where we would like them to align with 
> other
> windows without including shadows in those calculations (shadows are
> conceptually immaterial things, so should not cause a visual gap).
>
> given that our popup applets also have semantics similar to menus, it
> matters
> there as well.
ok, that makes sense there
>
> i agree there are some cases where it doesn't matter.
>
>> This approach comes with an additional rendering cost inside KWin.
>
> has the cost been measured?
very difficult as it depends on:
a) driver
b) hardware
c) graphics system

What I have measured is the rendering of window decorations which is 
basically the pain point of our complete rendering stack and follows a 
similar approach to rendering (each side rendered to a pixmap, TFP done 
from it, rendered in addition to the window) as the shadows. All lags 
during animations are caused by that architecture - though mostly due to 
rendering the decorations in the same thread as the compositor.

It's not exactly comparable to the shadow situation as the shadows are 
rendered out of KWin process and are not supposed to be change and 
stored in one texture. But still if the combination of the three points 
above is bad, it can cause a lack during first TFP operation.

Overall it has an impact due to the OpenGL state changes, but how much: 
depends, though for most cases not badly.
>
> this is the most important thing imho. if it costs us 10fps maybe it
> matters.
> if it costs us 1fps maybe it doesn't.
>
>> We need
>> to create textures from multiple pixmaps, we don't have the window 
>> as a
>> consistent texture any more (causes rendering glitches with various
>> effects) and we need several rendering passes - one for the shadow, 
>> one for
>> the window.
>
> the shadow+windowframe is not cached somewhere?
no that doesn't make sense as the window content changes.

Cheers
Martin