Consider changing sf::Texture::invalidateMipmap() from private to public

[selendym]

Prerequisite Checklist

• I searched for existing issues to prevent duplicates
• I searched for existing discussions on the forum to prevent duplicates
• I understand SFML's scope and believe the feature fits it

Describe your feature request here

Hello.

I'd like to suggest making sf::Texture::invalidateMipmap() public, if possible, as it is currently private for no apparent reason, other than lack of a use case.

There is some earlier discussion about this here; to quote:

I don't see any reason to make it public if we already make sure any modification by the user results in proper invalidation.

The problem with this reasoning is that even if the texture data does not change, the texture appearance does change between having mipmaps generated and not having them.
Currently, there is only a way to enable them, while disabling requires reloading the texture, which is less than optimal.
My use case for sfml is image viewing, so even slight changes in the perceived appearance are quite important.

Best regards.

Use Cases

• image viewing
• conserving gpu memory by dropping generated mipmaps while retaining the texture
• api consistence: if something can be enabled, it should be possible to disable it too

API Example

No response

[eXpl0it3r]

the texture appearance does change between having mipmaps generated and not having them

Can you elaborate what "texture appearance" means?

api consistence: if something can be enabled, it should be possible to disable it too

So is this about fully disabling the mipmaps or just invalidating the generate ones (those are two different features)?

[selendym]

Can you elaborate what "texture appearance" means?

I mean the effect that generating mipmaps has on what is drawn on the screen.
My observation has been that without mipmaps, the result is sharper but more jagged, while with mipmaps it is blurrier but smoother.
I can add an example if needed.

So is this about fully disabling the mipmaps or just invalidating the generate ones (those are two different features)?

To be honest, I'm not sure I understand the difference here.
What I mean is to undo (at least visually, even if resources are not freed) the effect that generating mipmaps has.
I've assumed that this is what invalidating mipmaps does, but feel free to correct me if I'm wrong.
Currently, I've achieved the above by reloading a texture (without generating mipmaps), but this feels somewhat wasteful, since the texture data itself doesn't change.

[eXpl0it3r]

My observation has been that without mipmaps, the result is sharper but more jagged, while with mipmaps it is blurrier but smoother.

You said, you're making an image view application. I assume you're display the image at a lower resolution than the texture has?
That would explain why you get a scaled down version with generated mipmaps.

One thing that's unclear to me is, why do you generate mipmaps in the first place if it creates an undesired effect?

To be honest, I'm not sure I understand the difference here. What I mean is to undo (at least visually, even if resources are not freed) the effect that generating mipmaps has. I've assumed that this is what invalidating mipmaps does, but feel free to correct me if I'm wrong. Currently, I've achieved the above by reloading a texture (without generating mipmaps), but this feels somewhat wasteful, since the texture data itself doesn't change.

Okay, yeah it's a subtle difference, but you just want to disable it and not having regenerated or similar (i.e. invalidation doesn't necessarily imply disabling).

[selendym]

You said, you're making an image view application. I assume you're display the image at a lower resolution than the texture has?
That would explain why you get a scaled down version with generated mipmaps.

Yes, it's an interactive image viewer, so zooming in and out is core functionality.
The effect mipmaps have is mostly noticeable only when displaying huge images zoomed out considerably, say, a 8000x8000 image zoomed out to fit a 1920x1080 screen.

One thing that's unclear to me is, why do you generate mipmaps in the first place if it creates an undesired effect?

Whether or not mipmaps have an undesired effect depends on at least image content, zoom level, and user preference, so I've provided an on-off toggle key to match this.
Effectively, this makes mipmaps just another visual filter, much like the smoothing filter.
By toggling mipmaps on and off the user can choose which one to use for that particular situation, so it's not really in my power to say "this one is better".

I understand this might be too niche a use case to justify any changes in sfml.
My initial assumption was that the functionality already exists in sfml but is just private and making it public would solve the issue.
If this is not so, I have a hard time justifying anything more extensive, since this is only a slight inefficiency and reloading a texture does the job reasonably well.