D5928: Introducing Night Color - KWin's native blue light filter at nighttime

[Roman Gilg]

subdiff added a comment.


  In https://phabricator.kde.org/D5928#111959, @davidedmundson wrote:
  
  > As for your comments:
  >
  > > The first one is, that the fading phases generate much DBus traffic, as you said. To solve this we would need to do the fading in KWin. For that we need timers, at least one. But it would make sense to have two timers, one for quick adjustments and one for long fades. >Because imagine the following:
  >
  > Not really. With any gradient or animation, you specify: startpoint, startvalue, endpoint, endvalue
  
  
  You forgot that we have a step size bigger than 1 on shifting the integer value of the color temperature (right now 50). QVariantAnimation also doesn't seem to support it directly.
  
  > With that your "imagine the following" is easily solved, if you get a new sunset time or filter value you can immediately deduce the correct "current" value.
  
  It's not about deducing the current value (we already do that in `currentTargetTemp()` - without use of the timers). It's about a two step operation: Changing to the currentTargetTemp and then (re)starting the slow fade process. The change to currentTargetTemp is suppposed to be faded as well (that's done by `m_quickAdjustTimer`) and afterwards in step two we go through the slow fade (`m_slowUpdateTimer`) or create a timer for the next slow fade to start (`m_slowUpdateStartTimer`).

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D5928

To: subdiff, #kwin
Cc: cfeck, graesslin, davidedmundson, plasma-devel, kwin, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein, lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170528/4c207768/attachment-0001.html>