plasma and new shadow mess

[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.

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?

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?

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130107/b6aa978e/attachment.sig>