NatronGitHub / Natron

Open-source video compositing software. Node-graph based. Similar in functionalities to Adobe After Effects and Nuke by The Foundry.
http://NatronGitHub.github.io
GNU General Public License v2.0
4.54k stars 332 forks source link

Fix mipmapLevel/RenderScale bugs related to overlay code. #919

Closed acolwell closed 9 months ago

acolwell commented 9 months ago

Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:

PR Description

What type of PR is this? (Check one of the boxes below)

What does this pull request do?

Have you tested your changes (if applicable)? If so, how?

I tried to find places where I could test these changes, but it appears that these 2 behaviors are not actually observed by any of the Natron plugins or nodes that they would affect.

The first fix is observable in changedParam() callbacks in plugins like HSVTool, Grade, Noop, ColorLookup, etc. but none of those plugins actually use the RenderScale value. The RenderScale gets passed to the plugin's processor and then the value is completely ignored during processing. I've verified the value passed to these plugins is correct now, but this doesn't appear to actually affect their behavior because they were not using the values to begin with.

The second fix is also observable, but existing code does not use the values. OFX Plugins don't receive the overlay double click event so there is no impact there. The RotoPaint and Tracking code ignore the render scale parameter for double click events so there is no impact to that code right now either.

Futher details of this pull request

I came across these issues while exploring some RenderScale/mipMapLevel refactoring ideas. Even though these issues aren't causing problems in the existing code, it seems worth fixing them. They could cause problems if the RenderScale values ever did get used and they are inconsistent with similar code.

acolwell commented 9 months ago

nice catch! what about also renaming getCurrentRenderScale to getCurrentMipmapLevel , to avoid confusion? (btw, Mipmap or mipmap is wrongly capitalized MipMap or mipMap at many places), including this one)

Thanks. Yeah. I was planning on doing that function renaming and some related duplicate code cleanup in a follow up. I was just trying to resolve the inconsistencies first. I was kind of wondering about the mipmap vs mipMap capitalization. I've seen both everywhere and wasn't sure which was preferred.

devernay commented 9 months ago

according to wikipedia, it's either mipmap or MIP map (MIP=multum in parvo), so that mipMap and MipMap are both wrong. I think most textbooks just say mipmap now

acolwell commented 9 months ago

according to wikipedia, it's either mipmap or MIP map (MIP=multum in parvo), so that mipMap and MipMap are both wrong. I think most textbooks just say mipmap now

Yeah I've always seen it all lowercase so I was surprised when I saw the camelCase. I was just trying to blend in. I'm happy to fix this across the codebase in a follow up. mipMapLevel -> mipmapLevel renderMappedMipMapLevel -> renderMappedMipmapLevel etc.

devernay commented 9 months ago

👍