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

RFC: replace relative system/speed scale with user-defined transform callback #11539

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

expikr
Copy link
Contributor

@expikr expikr commented Nov 26, 2024

This is an accompanying Proof-of-Concept for #11449, requesting discussion on what to do with the relative speed scale hint (relative system scale hint should be replaced outright regardless):

Option 1: remove relative speed scale (this implementation)

This is my preference, as the scaling functionality can easily be folded into the developer-defined function. and the main problem raised in the issue is that developer may be surprised by the end-user being able to alter the behavior from environment variables, so it is necessary to move the control exclusively to the developer instead.

Option 2: apply relative speed scale if no custom transform

This is essentially the inverse of the current behavior but with custom rather than system transform. The end user alterable relative speed scale taking a lower precedence than developer-controlled transform function removes a large portion of the element of surprise for the developer. However, the issue might still exist for developers that want specific scaling values and expected to use the events system exclusively without knowing about this new callback functionality.

Option 3a: apply relative speed scale before custom transform

Essentially, this is a philosophical assertion that the end-user wants to have precedence over the behavior, that the inputs are uniformly scaled according to their specification before the developer code is made aware of it.

Option 3b: apply relative speed scale after custom transform

I cannot think of any good reason to do this, considering that this causes a divergence between what the developer expected from their transform output and when they receive the event by inserting an end-user configurable step in between.

@expikr expikr force-pushed the transform-function branch 5 times, most recently from 0f8feb0 to 240af6e Compare November 26, 2024 10:37
@expikr expikr force-pushed the transform-function branch 2 times, most recently from cb56a4e to 2cbc0c0 Compare November 26, 2024 15:43
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.

1 participant