Sfml: Feature request: implement getter for sf::Texture::m_pixelsFlipped

[eliasdaler]

Hello.

There's an issue that I've encountered during ImGui-SFML development.

When users use sf::RenderTexture and set it on sf::Sprite, it's impossible to know if sf::Sprite has texture set from regular Texture of from RenderTexture, which results in inverted image in the former case.
If sf::Texture::m_pixelsFlipped was accessible, I'd be able to check this an invert UVs that I pass to ImGui::Image here.

I think that this might be also useful for some shaders and other OpenGL interactions where it matters if pixels are inverted or not.

[eXpl0it3r]

My issue with such an API change is mostly that we're exposing an implementation detail, but at the same time I see the limitation SFML is creating for advanced use cases.

See also the technical explanation why it is implemented this way at the moment.

@binary1248 / @LaurentGomila do you see a way we can help with such use cases?

[binary1248]

I can understand the dilemma here.

Basically, because libraries want to be as nice to use as possible for users they don't want to force the user to have to tell them what they did with e.g. an sf::Texture so that the library can deduce whether it might be flipped or not. In order to appear to "just work" any library working with SFML will need the ability to be able to ask SFML what the user did with an sf::Texture, i.e. whether it is flipped or not.

As I mentioned in the other issue linked above, all of this is the result of OpenGL not providing a way to specify the "write orientation" when writing to a texture although specifying a "read orientation" was always possible. As such, as soon as sf::RenderTextures are in circulation there will always be a "risk" that a texture might be flipped from the otherwise expected orientation. There is no way around this.

Providing a getter for this information might seem like we are exposing an implementation detail, however I see it simply as a way of asking whether the texture was written to by OpenGL, which is a legitimate use case considering the limitations OpenGL imposes on us as I described. The typical worry of exposing implementation details is usually that we limit our implementation freedom because it becomes part of the public interface, however because this limitation stems from OpenGL itself (which let's face it is probably never going to change) I don't realistically see this part of the implementation having/going to change any time in the future.

The API change also doesn't break anything and has no performance cost if not used.

I support this.

[1aam2am1]

You could also rewrite all implementation of opengl part so that all textures are flipped. So in that way we don't need to know orientation because it is the same all the time.

[binary1248]

You could also rewrite all implementation of opengl part so that all textures are flipped.

I actually experimented with this a while ago (as part of experiments to get rid of the texture matrix). It looks doable on paper, however we still need real world data on this (performance, usability, etc.). There might be some edge cases in which it might not work as well.

[eliasdaler]

Also it'll probably be a breaking change? Some users might expect pixels in RenderTexture to be upside down and use this in shaders.

[binary1248]

@eliasdaler This would be a somewhat breaking change. One must also consider how many users have already been burned when trying to use multiple textures with differing orientations within a single shader as in #1733.

I don't want to have to make a decision on whether it makes sense to break existing behaviour in favour of less necessary workarounds. It's like people getting used to working with bugged code only to be surprised it actually gets fixed one day. In this case the decision is more difficult because the current behaviour wouldn't be considered as "bugged" just "surprising".

From a purely performance standpoint, having less logic inside a shader to switch between orientations will in theory lead to a performance increase since less work has to be done. The question is how often such use cases exist in the wild.