plasma and new shadow mess
mgraesslin at kde.org
Mon Jan 7 15:04:05 GMT 2013
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
>> 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
>> panel, for KRunner and the Oxygen menus.
> it also matters for tooltips where we would like them to align with
> 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
> 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:
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
> 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.
More information about the kde-core-devel