Comment # 15
on bug 108917
from tempel.julian@gmail.com
To clarify: There is no connection to any compositor. You can also reproduce the issue with any desktop environment where you can disable the compositor. Instead of using a compositor then, simply enable TearFree and run "redshift -t 4500:4500 -l 1:1". -> It still makes everything stutter. And not just with cursor input, it affects the whole screen content without further doing. Just look at your browser window content of www.vsnctester.com, scroll on any webpage or play a video: The stutter should always be noticeable. The commit "drm/amd/display: Allow cursor async updates for framebuffer swaps" has not changed the situation. I can't explain why this issue was less distinct with some 5.1 kernel versions. Anyway: It's back to "really stuttery" since 5.2. --- Is this perhaps because userspace uses legacy gamma adjustment instead of new atomic infrastructure? In that case, it would seem unrealistic to expect it to adopt to the new infrastructure if not even Gnome Nightlight on Wayland uses it. So a performance fix for legacy gamma adjustments would be highly welcome (if my assumptions apply ;) ). I also wonder why there has to be stutter at all. Only the initial setting of new gamma adjustments cause the stutter. When you run redshift in "oneshot" mode via "redshift -O 4500", there is no more stutter once the initial adjustment is done and the gamma stays adjusted. Perhaps it would help to make the kernel delay the adjustments until they can happen without causing performance issues with vsync + pageflipping?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
