| Summary: | Dynamic shadows to recognize Z-index of windows when calculating size | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Ken Vermette <vermette> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | danalien, hugo.pereira.da.costa |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Shadow diagram | ||
Created attachment 50036 [details]
Shadow diagram
*** Bug 107509 has been marked as a duplicate of this bug. *** as the shadows are currently drawn by oxygen I reassign to oxygen which also includes our designers. Will not happen on the oxygen side, sorry. 1/ I don't know of a way for the decoration to know the z index (Martin ? Is there such a way 2/ worse: what you really need is the relative z index with respect to the nearest window below 3/ even worse: you need to know the overlapping areas for partially overlapping areas. If I understand right, 3 can only be achieved by the compositor. Especially if oxygen only passes shadow *tiles* to kwin for kde 4.9 (right ?) So reassigning to kwin again (IMO it should have staid there from the start). On the oxygen side, its a WONT FIX. Martin, feel free to close. pre summary for martin: clear won't fix to me (but click the link on the end ;-) -- Ratio -- Not only is realistic shadowing utterly complex (try to imagine a convex client shape...), but would likely a) have bad impact on usability. b) not lead to some realistic experience at all a) as by now, the shadow is more or less used to hint the active client, if the shadow size of the active client would only marginally differ from the next one, this would be lost. b) it would only marginally differ because the desktop has no frustum, ie even clients deeeep down in the z axis have the very same appearance as the topmost one, what also means you'd try to sell that two paper thin clients in a few mm deep stack would cast two largely different shadows, in other words: THE REALISTIC APPROACH WOULD BE ONE SHADOW TYPE FOR ALL (and this doesn't consider that the oxygen deco glows around the active window, implying a (bluish) frontlight which is nowhere else reflected on the desktop. Sum up: a desktop is not realistic but a model with fancy eye candy. With wayland we're of course free to do sth. as the wolfenstein window manager =) http://labs.qt.nokia.com/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/ thanks for the summary and I quite agree that this is a wontfix |
Version: unspecified (using KDE 4.5.0) OS: Linux Currently shadows are drawn around a window without respect to their Z-Index. That this calls for is using successively deeper shadows as a window is "higher up". It can easily be accomplished with basic masking, and adds depth and dimension. Diagram attached: Top: Z-Indexing Bottom: Current Method Reproducible: Always Steps to Reproduce: Use composting with shadows. Actual Results: Shadows are not drawn with respect to Z-index Expected Results: Addition of feature would darken and shrink shadows overtop higher windows, getting deeper and fuzzier for lower windows and the desktop, creating a height effect based on Z-index. This idea moves window shadows from the realm of statically drawn and relatively flat to dynamically drawn. The Kwin shadow effect plugin would require some additional settings changes to implement this effect. - 2 shadow settings would be given, one for shallow and the other for deep shadows. Kwin could have an autoguess setting for the second shadow. - If the top window is to be given a glow effect though this plugin still, a third shadow option ("active glow") might need to be considered. - Autoguess for deep shadows would likely double the size of the shallow shadow and cut it to 2/3rds intensity. The actual implementation would likely use the following process to draw shadows; 1) Bottom window would cast the 'shallow' shadow on the desktop. 2) The next window up would cast the 'shallow' shadow on the bottom window. The plugin would mix the two depth settings for deep and shallow to create a slightly deeper shadow to cast on the desktop; calculating this by its z-index and the number of windows in total. 3) Then, repeating step 2, each window would cast the most shallow shadow on the window directly below, using successively deeper shadows as they are cast towards the desktop. 4) The top window would always cast the deepest setting of shadow on the desktop, still casting the most shallow shadow on the window directly underneath. #) If only one window is on the desktop, it would cast a shallow shadow. #) When new windows are opened shadows would need to be re-calculated #) Some shadows might be kept "dumb" (or have the option) to prevent constant re-rendering. Ie tooltip shadows. #) Because the addition of a new window means re-sizing shadows, an option to smoothly re-size shadows should be present to make the change less noticeable.