| Summary: | Night light transition can cause stutters | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | madness742 |
| Component: | night color | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | nate, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.5.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
madness742
2025-12-12 11:13:26 UTC
Id the transition causes a problem, the solution is to fix the issue, not provide a way for people to work around it! Let's focus on the issue itself, and see if there's anything we can do in KWin until the driver bug is fixed. This is quite challenging to fix tbh. There's two things that need to happen for this: 1. we need new API so KMS won't drop any frames when programming a new LUT is slow. There have been some ideas for this before, like allowing the compositor to program color properties for a future frame, without actually applying it yet, so it's decoupled from the current frame. 2. if the LUT is not immediately applied, we have to fall back to a shader There is however some risk that implementing the fallback will also cause some slight stutter, because KWin has to allocate some shadow buffers and do an additional copy, which increases how long KWin has to render vs. previous frames. Another possibility is that KWin starts programming the frame a lot earlier if a lut needs to be programmed, but we don't actually know how long programming it takes on each hardware, so that's also very difficult. |