-
Notifications
You must be signed in to change notification settings - Fork 190
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
Magic Resolution consistency/override #399
Comments
It's tempting to try to use context.RequestedResolution (like the new SetRequestedResolution), however I see 2 problems with this approach:
|
Thanks for the feedback. You're correct in that ideally all ops using [GetTextureSize] should publish this parameter to allow an override. In practice, I have to admit, I'm hesitant to implement everything that would be consistent because I'm afraid that that many operators would suffer from too many parameters. Also there is a small performance overhead by the added parameter. On the other hand, I recently stumbled over the same issue. So I added [SetRequestedResultion] after our discussion on discord. |
if I understand correctly from the video https://www.youtube.com/watch?v=f9E7lwUXfBM
for -1 use output resolution
for 0, use resolution from source if available, fallback on output resolution (resolution flows from left to right)
(else use the fixed width/height values)
Internally, this seemed to be handled through GetTextureSize, however, for instance inside CustomPixelShader,
the texture input is not connected to GetTextureSize which breaks expected behaviour (is this a bug? or a deliberate exception?)
I feel the concept outlined in the video is great, but in order for the user to have control over resolution in this intuitive way, all operators that internally uses an operator with a resolution should also expose a resolution input and handle it consistently.
The text was updated successfully, but these errors were encountered: