| Summary: | Present windows animation: Windows do a little jump at the end. | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Björn Sonnenschein <green> |
| Component: | effects-present-windows | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | karthik.periagaram, nate |
| Priority: | NOR | Flags: | thomas.luebking:
ReviewRequest+
|
| Version: | 4.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/111276/ | ||
| Latest Commit: | Version Fixed In: | 5.23 | |
| Sentry Crash Report: | |||
|
Description
Björn Sonnenschein
2013-02-08 21:31:52 UTC
Do you use opengl compositing and "accurate" scaling? What if you set scaling to "smooth" instead? This is btw. hardly notable here even when settign the animation speed to "extremely slow" - ooc: what speed setting do you use? I use opengl and accurate scaling, but have tried all other scaling methods which do also show the problem, and I have checked that it occours with every layout mode. I use normal speed and if you know what to look for, it is clearly visible most time, while it is useful to have four or more maximized windows opened so that much scaling is happening during the animation. If you change the speed to extremely slow, you may clearly see a bounce move at the end of the animation. I have no Idea how the effect works (will look through the code next days), but isn't it possible to detect the active window and scale it it's final size during the animation and so don't scale it to the size of inactive windows at first? Sorry, the above comment was postet to the wrong bug, please delete... I thought this was the intended behavior and as such, is a rather pleasing effect. The windows overshoot the ending position and double back. The amount of jumping back is also seemingly proportional to the distance the window traveled to get there. Feels more organic that way, like the windows accelerated, then decelerated, but not enough, so they overshoot and reverse into position. I'm not sure this should be considered a bug. Hmm, at least at normal speed it doesn't look like a natural motion for windows with a large traveling distance because the traveling back effect lasts only for approx. 2-3 frames and so is more percepted as a jump rather than a motion in my opinion. Maybe it would be nicer if the transition from the linear to the backtravel phase would be smoother and start a little earlier so that the acceleration curve is something like an S shape? Not 100% sure whether this is what is meant. Maybe have a look at the patch. Git commit d2d71aaa4f5fa18e79757712def78cb4d4314345 by Thomas Lübking. Committed on 27/06/2013 at 19:54. Pushed by luebking into branch 'master'. Don't highlight hoverd window while PW start/stops Instead have a synthetic motion after the effect started and explicitly set the selected window on click/drags Related: bug 314840, bug 314715 FIXED-IN: 4.11 REVIEW: 111276 M +16 -3 kwin/effects/presentwindows/presentwindows.cpp M +1 -0 kwin/effects/presentwindows/presentwindows.h http://commits.kde.org/kde-workspace/d2d71aaa4f5fa18e79757712def78cb4d4314345 This is fixed in the QML rewrite for Plasma 5.23! |