Hello, desktop effects, especially noticeable on Minimize Animation, Magic Lamp, Glide, and possibly others happen to be very jerky, but are smooth and fast if I enable the Show FPS effect. Reproducible: Always Steps to Reproduce: 1. By default effects are jerky. 2. Enable Show FPS, and effects are smooth. 3. Disable Show FPS, effects are jerky again. Actual Results: Jerky desktop effects. Expected Results: Smooth and fast desktop effects. Open source 'radeon' driver on ATI RS880, Amd 965 BE 3.4Ghz quad cpu, 4GB ram (512 shared vram), Radeon HD 4250.
please provide output of: qdbus org.kde.kwin /KWin supportInformation
(In reply to comment #1) > please provide output of: > qdbus org.kde.kwin /KWin supportInformation http://paste.kde.org/589868/
Please try enabling the VSync option in the advanced desktop effects settings
(In reply to comment #3) > Please try enabling the VSync option in the advanced desktop effects settings I have tried and found that the desktop effects remain jerky regardless of Use VSync being enabled or not.
a) was it the same with MESA 8.x b) how's the behavior on XRender (last tab of "kcmshell4 kwincompositing") c) try raising the MaxFPS "kwriteconfig --file kwinrc --group Compositing --key MaxFPS 120; kwin --replace &" d) how's the behavior on fglrx?
(In reply to comment #5) > a) was it the same with MESA 8.x > b) how's the behavior on XRender (last tab of "kcmshell4 kwincompositing") > c) try raising the MaxFPS "kwriteconfig --file kwinrc --group Compositing > --key MaxFPS 120; kwin --replace &" > d) how's the behavior on fglrx? I cannot answer for a) and d). I have never tested on MESA 8.x and right now fglrx is not compatible with my graphics chip because AMD has dropped support and I'm not sure if catalyst-legacy has support for new xorg 13. It didn't work for me when I tried to install it. Performance in XRender seems to be acceptable and haven't noticed jerkiness. c) is bang on! Using that command, the effects are now smooth. Hope whatever the problem was will now be fixed.
It smells as if there's soem extra implicit sync in the driver (glswapinterval forced to one) causing you to miss the repaint. Can you please try a lower value (61, but the fast approach to determine a limit is to bisect, ie 90 -> 75|105 -> ..) and share your observations? If you're able to incorporate a patch: see bug #307965 (enable vsync to gain any impact, the "unsynced" path has a constant repaint interval)
(In reply to comment #7) > It smells as if there's soem extra implicit sync in the driver > (glswapinterval forced to one) causing you to miss the repaint. > > Can you please try a lower value (61, but the fast approach to determine a > limit is to bisect, ie 90 -> 75|105 -> ..) and share your observations? > > If you're able to incorporate a patch: see bug #307965 (enable vsync to gain > any impact, the "unsynced" path has a constant repaint interval) If I understand correctly, I'm supposed to replace the MaxFPS value in the command with '90 -> 75' and so on. I tried 120 and 90 -> 75, in both the animation was fast enough that jerkiness was not noticeable and not a bother. I tried just 75, and I thought I detected extremely slight jerkiness, but it was not a distraction and probably just my mind. Then I tried 61, and there is noticeable jerkiness. You want me to try which patch? The one labelled Hanukkah #2 by Thomas Lubking?
(In reply to comment #8) > (In reply to comment #7) > > It smells as if there's soem extra implicit sync in the driver > > (glswapinterval forced to one) causing you to miss the repaint. > > > > Can you please try a lower value (61, but the fast approach to determine a > > limit is to bisect, ie 90 -> 75|105 -> ..) and share your observations? > > > > If you're able to incorporate a patch: see bug #307965 (enable vsync to gain > > any impact, the "unsynced" path has a constant repaint interval) > > If I understand correctly, I'm supposed to replace the MaxFPS value in the > command with '90 -> 75' and so on. No =) by either "90" or "75" or ultimately "61"m but you figured that already 61 did it. What about explicitly setting "60" (should be default) > You want me to try which patch? The one labelled Hanukkah #2 Yes, but i'm gonna add an updated patch and review request in a couple of minutes, just wait for that.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > It smells as if there's soem extra implicit sync in the driver > > > (glswapinterval forced to one) causing you to miss the repaint. > > > > > > Can you please try a lower value (61, but the fast approach to determine a > > > limit is to bisect, ie 90 -> 75|105 -> ..) and share your observations? > > > > > > If you're able to incorporate a patch: see bug #307965 (enable vsync to gain > > > any impact, the "unsynced" path has a constant repaint interval) > > > > If I understand correctly, I'm supposed to replace the MaxFPS value in the > > command with '90 -> 75' and so on. > No =) by either "90" or "75" or ultimately "61"m but you figured that > already 61 did it. > What about explicitly setting "60" (should be default) > > > You want me to try which patch? The one labelled Hanukkah #2 > Yes, but i'm gonna add an updated patch and review request in a couple of > minutes, just wait for that. Hello, Explicitly setting 60, there is also jerkiness. I haven't gotten around to trying that patch yet. It is for 4.9.2, isn't it? because strangely the kwin/glxbackend.cpp file doesn't seem to be there is my distro's srpm for kde-workspace.
*** Bug 293274 has been marked as a duplicate of this bug. ***
Please confirm or deny that this bug is (still) present with 4.11.2 - there's been a bug in the paint time measuring.
Thomas Lübking: There seem to be new options in KDE 4.11.2, I tried them out and, yes, the bug is still present, except starting Show FPS no longer yields performance gains in the OpenGL animations. - OpenGL 3 and OpenGL 2 with Native or Raster are very jerky and unusable. - OpenGL 1.2 in Native mode is jerky. in Raster mode it is smoother but still jerky and not acceptable - Above is compared to XRender Raster which is butter smooth but when there are two windows on top of each other, the minimize animation, etc is unsmooth and jerky. Also in Native mode, it is more jerky. I would like to see this bug fixed soon, as using kde is a pain to the eye.
In order to fix it, we'd have to know what the problem is. My initial guess would have been powersaving: https://wiki.archlinux.org/index.php/ATI#Powersaving But then you claimed altering the MaxFPS value would do (still does?) and the ShowFPS plugin no longer had any impact. -> Please attach a current output of "qdbus org.kde.kwin /KWin supportInformation" and "xrandr -q" (attach it to the bug, do *not* use paste.kde.org or any other paste with limited lifetime)
Hi, I'm not sure if it's the powersaving. The issue was present in the default powersaving before kernel 3.11 and is present with kernel 3.11 with the new dpm enabled. I'm not familiar with the linux powersaving things and how it affects my card (Radeon HD 4250/RS880) but setting this two things did not help: sudo bash -c "echo performance > /sys/class/drm/card0/device/power_dpm_state" sudo bash -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level" Sorry if the commands are wrong, I'm fairly new to linux and don't have perfect understanding of terminal. To clarify, enabling ShowFPS plugin did make everything perfect in the version of kde used when I first reported (4.9.2), and it doesn't help in kde 4.11.2 (I haven't tested the versions in between as I use another environment by default. About MaxFPS, I'm unsure how much if it actually helped in 4.9.4 (I don't remember well) but, no, it doesn't make effects smoother in 4.11.2. Attaching your required outputs shortly.
Created attachment 82931 [details] xrandr -q output
Created attachment 82932 [details] kwin support information output
Try disabling tearing prevention and raising the MaxFPS value again. (The value is internally capped to the refresh rate) If you set the tearing prevention to "full scene repaints" you'll likely have the problem all the time (not only wuth some effects)?
OK, I raised MaxFPS value to 999 and using OpenGL 1.2 (raster) - I'm not sure what caused it but now some of the effects (except for say, Minimize animation) happen in very slow motion, moving windows, window fade on close are happening in very slow motion. (Tearing prevention set to none). I switched to Xrender Raster and everything happens in slow motion in that too, including minimize animation, moving windows, window fade on close, etc.. With tearing prevention set to full scene repaints and using OpenGL 1.2 raster, it's not slowmotion but minimize and unminimize is jerky and unsmooth.
> OK, I raised MaxFPS value to 999 Sounds as if you ran out of CPU/GPU (you repaint so fast that there's not enough GPU to do the other important stuff) a) does it become "smoother" when you *lower* the framerate to 30FPS b) what about a more realistic FPS target like 120?
OK, sorry about that. It seems that MaxFPS set to 30 and set to 120 don't appear to be smoother compared to each other and are significantly jerky as the effects were with default settings. The only thing I can definitiely say for sure is that OpenGL 1.2 raster is significantly smoother (regardless of MaxFPS) than 2.0 and 3.0 in native or raster modes but still noticeably unsmooth compared to Xrender raster which is what I think is pretty normal except minimize animation is jerky when more than one window is open. With OpenGl 1.2 (or other OpenGL options, for that matter) I can't tell a difference between setting MaxFPS to 30 or 120 or default.
Stupid question: how's the behavior with the "Laptop" decoration ("kcmshell4 kwindecoration") or the animations of the oxygen decoration disabled? (run "oxygen-settings")
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
This issue report is quite old. Can you please confirm, that it still persists with Plasma 5.23?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!