How can I get this 'curve' / is this possible?
Look I am sorry for my horrible drawing skills, but do you see what I am asking?
How can I achieve a similar curve? Please guide me since I wasn't able to find the right settings.
(yes i drew with red)
TwoCables last edited by TwoCables
It's not something we users can do. Even if we could do it, that would constantly use your CPU the entire time. There are 2 problems with this:
- On battery-operated systems, it would cause batteries to die fast
- It could introduce performance problems on some slower systems during the entire length of this long transition.
@TwoCables okay I see, how about this? It would solve the problem you presented, wouldn't it?
(drew with green so you know it's better for your pc :D )
TwoCables last edited by TwoCables
I guess, but there is scientifically and biologically no problem with the way f.lux works currently. The whole point of f.lux is to help you avoid being exposed to alerting blue light when it's best not to be.
@TwoCables Thank you for your quick replies.
f.luxyFox last edited by
@twocables ... Hi, are you on the dev team for this product? The reason I ask is I don't want to throw out opinions or assumptions where your statements may be based on fact/source code...
That being said I don't see how this would significantly affect performance. If the "dimming/recoloring" value was floored or stepped by whatever value was the minimum perceptive difference to most users you would likely have at most two additional operations (i.e. rewrite dimming factor variable, retrieve values for next dimming factor change) per five or ten seconds. And probably significantly less than that in most use cases.
Most of the calculation for dimming values and corresponding times could be done on the front end when the custom dimming curve was committed to the config, and those values could be stored in a table.
The current minimum step value of the f.lux software version I'm using is 50k. Say the user wants to dim from 6500k (daylight setting) to 2000k over a 2 hour period. That is 90 increments, 80 seconds between each increment. That's also only 90 values that need to be stored. If each entry in the table takes up (I'll assume worst case here) 64B then the table would only take up 6KiB, 10 at most. Even if this was all stored in memory this would be unnoticeable. The program itself would be slightly larger in memory, but not by much... and if the setting was not being utilized by the user that module wouldn't even need to be stored in memory.
So in reality, the cost of this feature would be ~90 relatively simple value pair calculations at initialization, a few additional clock cycles at each dimming factor change during runtime, some additional code in memory for the module, and ~10KiB of either storage and/or memory for the value table.
Seems very feasible for a feature that I'm sure is desired by more people than just me.
It is also worth noting that the f.lux software is already performing most of these operations as it is deployed today. When it changes dimming factors at sunset and bedtime, it doesn't just suddenly change colors. It cycles down through the spectrum (it appears to use an acceleration function as well (starts slow, gets faster, slows back down) based on the GUI) changing the dimming factor of the display for each of those steps. I assume they're using the 50k value as their step value, as it wouldn't make much sense to write that code twice.
Again, I obviously don't have access to the source code so I don't know for sure how something like this might impact performance.... however, if there were the potential (in certain use cases) that this would be non-performant then it could be deployed as an advanced option module so that in circumstances where the additional costs were worth the gain to the end user (e.g. desktops) it was available.