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

Fix rendering images with nearest sampling and 2^n size #11162

Merged
merged 13 commits into from Oct 27, 2021

Conversation

SnailBones
Copy link
Contributor

@SnailBones SnailBones commented Oct 22, 2021

Closes #11132

This code appears to be attempting to use mipmaps when textures are a power of two square:

if (minFilter === gl.LINEAR_MIPMAP_NEAREST && !this.isSizePowerOfTwo()) {
minFilter = gl.LINEAR;
}

In the case where we pass in bind(gl.NEAREST, gl.CLAMP_TO_EDGE, gl.LINEAR_MIPMAP_NEAREST), we get:

            gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
            gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR_MIPMAP_NEAREST);

In this case rendering doesn't work as intended, instead drawing every pixel black.

By replacing gl.LINEAR_MIPMAP_NEAREST with gl.LINEAR this issue appears to be fixed.

Before:

Image on the right has paint property 'raster-resampling': 'nearest'

Screenshot 2021-10-22 at 10-39-09 Mapbox GL JS debug page

After:

Screenshot 2021-10-22 at 10-36-10 Mapbox GL JS debug page

Launch Checklist

  • briefly describe the changes in this PR
  • include before/after visuals or gifs if this PR includes visual changes
  • write tests for all new functionality
  • manually test the debug page
  • apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
  • add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Fix rendering issue with power of two square images and 'raster-resampling': 'nearest'</changelog>

@SnailBones SnailBones changed the title Added render test for image with a power of 2 size Fix rendering images with nearest sampling and 2^n size Oct 22, 2021

context.activeTexture.set(gl.TEXTURE0);
tile.texture.bind(textureFilter, gl.CLAMP_TO_EDGE, gl.LINEAR_MIPMAP_NEAREST);
tile.texture.bind(textureFilter, gl.CLAMP_TO_EDGE, minFilter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we fixing this at the correct level, have you considered whether there is something incorrect within the internal texture class?

I feel like the texture class could be safer for the developer based on intent. At the moment it's possible to call texture.bind(filter, a_mip_map_filter), without necessarily having created the texture with a call that falls through generateMipMap(), resulting in an incoherent mipmap filter set on a texture that doesn't have any mipmap created.

We could assert or warn if from the callee we request that combination to prevent silent failure.

The flag this.useMipmap in that class may be misleading, because it may be set to true, but might not represent the internal state of whether that texture uses mipmaps. I'd suggest replacing it with this.canUseMipMaps = Boolean(options && options.useMipmap) && isPowerOfTwo().

Then, at binding:

bind(...): 
   if (minFilter is mipmap filter && !canUseMipMaps) {
      incoherent filter request: no mipmap created and requested a mipmap filter, fallback to minFilter = filter
   }
   ...

@SnailBones
Copy link
Contributor Author

SnailBones commented Oct 26, 2021

I feel like the texture class could be safer for the developer based on intent. At the moment it's possible to call texture.bind(filter, a_mip_map_filter), without necessarily having created the texture with a call that falls through generateMipMap(), resulting in an incoherent mipmap filter set on a texture that doesn't have any mipmap created.

I agree @karimnaaji , this is exactly what's causing this issue.

There's currently a check that's replacing gl.LINEAR_MIPMAP_NEAREST with gl.LINEAR unless size is a power of two. (This replacement is skipped regardless of filter, I'm not sure why rendering fails when is combining a failed mipmap lookup with gl.NEAREST but not gl.LINEAR)

if (minFilter === gl.LINEAR_MIPMAP_NEAREST && !this.isSizePowerOfTwo()) {
minFilter = gl.LINEAR;
}

In my latest commits, I've refactored this check to change gl.LINEAR to gl.LINEAR_MIPMAP_NEAREST if and only if this.useMipmap is true, which now corresponds to whether gl.generateMipmap is called. (so I think sticking with the name "useMipmap is appropriate.) This allowed me to remove minFilteras an argument to texture.bind().

I see two potential issues with my change, both seem unlikely:

  • This could be a breaking change if users are making use of texture.useMipmap.
  • If there's a time when we would NOT want to use mipmaps after generating them, this change breaks that.

@SnailBones SnailBones marked this pull request as ready for review October 26, 2021 22:54
Copy link
Contributor

@karimnaaji karimnaaji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find and fix! One nit about keeping mipmap sampling when we use NEAREST after requesting a texture with mipmap as an option. Otherwise LGTM.

gl.generateMipmap(gl.TEXTURE_2D);
}
}

bind(filter: TextureFilter, wrap: TextureWrap, minFilter: ?TextureFilter) {
bind(filter: TextureFilter, wrap: TextureWrap) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on removing the extra parameter as it really simplifies use of that class (basically infers that from the option request to use mipmaps).

if (filter !== this.filter) {
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, filter);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, minFilter || filter);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, (this.useMipmap && filter === gl.LINEAR) ? gl.LINEAR_MIPMAP_NEAREST : filter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 That's the correct fallback a filtering request on LINEAR.

For NEAREST, if we request texture.bind(NEAREST, ...) I would still expect as a user of this class to fallback to NEAREST_MIPMAP_NEAREST (nearest within the mip level and nearest between mip levels).

It seems that most of our use cases need to stay non-linear between mip level as a default (we're not using trilinear, but we could extend that when we need it for some cases, e.g. LINEAR_MIPMAP_LINEAR), so we can stick to that for now but still hint the requested filter for within the mip (e.g. filter_MIPMAP_NEAREST).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practice what that means as a fallback in this case:

  • LINEAR + mipmap -> LINEAR_MIPMAP_NEAREST
  • NEAREST + mipmap -> NEAREST_MIPMAP_NEAREST

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! Happy to add the condition for nearest with mipmap. In practice I don't think this is ever happening, but not a bad idea to future-proof it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a possible combination when a user chooses nearest as a paint properties with raster-resampling because we always request mipmaps for it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense! I noticed that code path didn't run in my example, but it should now correctly use mipmaps when it is called. (Repeating textures?)

@karimnaaji
Copy link
Contributor

This could be a breaking change if users are making use of texture.useMipmap.
If there's a time when we would NOT want to use mipmaps after generating them, this change breaks that.

This class is only used in internal code so no worry about that. There's only one case at the moment where we explicitly request mipmaps (raster_tile_source) so this isn't breaking usage.

@karimnaaji karimnaaji merged commit 309c54b into main Oct 27, 2021
@karimnaaji karimnaaji deleted the aidan/image-black branch October 27, 2021 16:32
@SnailBones SnailBones self-assigned this Oct 27, 2021
ansis pushed a commit that referenced this pull request Nov 4, 2021
* Added render tests for image with a power of 2 size

* Added nearest resampling, test is failing

* Fix by disabling mipmaps

* Keeping same behavior with linear sampling

* Correcting expected.ping to use nearest filtering

* Adding check for useMipMap

* Refactoring

* Removing third argument from

* Fix broken refactoring

* Removing stray console.log

* Readd mipmaps

* minor refactor

* Mipmaps with nearest
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Black square is displayed when adding a source image (size 64 * n px)
2 participants