Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another logic for handling interval of fade_brightness() within __init__.py #36

Merged
merged 3 commits into from
Mar 4, 2024

Conversation

BingoWon
Copy link
Contributor

@BingoWon BingoWon commented Mar 3, 2024

Previously, interval was defined as the time delay between the end of one brightness change and the start of the next. This meant that the actual time between brightness changes was always longer than the specified interval, as it included the time taken by the brightness change itself. This resulted in the total fading time being longer than interval*steps, with the deviation increasing with more steps. This resulted in unpredictable time consumption.

This PR adds a new parameter strict_interval to the fade_brightness(). interval can now be interpreted as the intended time between the start of each brightness change. However, if a brightness change takes longer than the specified interval, the actual interval will be longer, as the next change can't start until the current one finishes.

test result:

start=1 finish=21
-----------------
interval=0.01s expected=0.2s
before=1.94s deviation=1.74s
after=1.46s deviation=1.26s
time_saved_percent='239.95%'
-----------------
interval=0.05s expected=1.0s
before=2.58s deviation=1.58s
after=1.63s deviation=0.63s
time_saved_percent='103.58%'
-----------------
interval=0.1s expected=2.0s
before=3.70s deviation=1.70s
after=2.19s deviation=0.19s
time_saved_percent='75.81%'
-----------------
interval=0.5s expected=10.0s
before=11.62s deviation=1.62s
after=10.19s deviation=0.19s
time_saved_percent='14.25%'
-----------------
interval=1s expected=20s
before=22.17s deviation=2.17s
after=20.21s deviation=0.21s
time_saved_percent='9.81%'
-----------------

test code:

import screen_brightness_control as sbc
import time

start = 1       # included
finish = 21     # included
intervals = [0.01, 0.05, 0.1, 0.5, 1]
print(f"{start=}\t\t{finish=}")
print("-----------------")

for interval in intervals:
    expected = interval*abs(finish-start)
    print(f"{interval=}s\t{expected=}s")
    kwargs = {"finish": finish, "start": start, "increment": 1, "interval": interval, "logarithmic": False, "display": 0}
    
    t1 = time.time()
    kwargs["strict_interval"] = False
    sbc.fade_brightness(**kwargs)
    t2 = time.time()
    before = t2-t1
    deviation = before-expected
    print(f"{before=:.2f}s\t{deviation=:.2f}s")
    
    kwargs["strict_interval"] = True
    sbc.fade_brightness(**kwargs)
    t3 = time.time()
    after = t3-t2
    deviation = after-expected
    print(f" {after=:.2f}s\t{deviation=:.2f}s")
    
    time_saved = before-after
    time_saved_percent = f"{time_saved/expected*100:.2f}%" if expected != 0 else "can not be calculated"
    print(f"{time_saved_percent=}")
    print("-----------------")

This change makes the time consumption of fade_brightness() more predictable. Note that this PR is not intended to make the time consumption equal to the expectation, but to bring it closer.

Furthermore, I recommend removing the strict_interval and making this new interval handling logic the default and only method.

@BingoWon BingoWon changed the title Another logic for handling interval parameter of fade_brightness function within __init__.py Another logic for handling interval of fade_brightness() within __init__.py Mar 3, 2024
@Crozzers
Copy link
Owner

Crozzers commented Mar 3, 2024

Thanks for this. Makes alot of sense.

Furthermore, I recommend removing the strict_interval and making this new interval handling logic the default and only method.

I agree. Can't see much reason for keeping the old behaviour around

@Crozzers
Copy link
Owner

Crozzers commented Mar 4, 2024

LGTM. Thanks for this!

@Crozzers Crozzers merged commit 6aa6be9 into Crozzers:dev Mar 4, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants