Texture upside down with Android

[Nafffen]

Working with Canvas to draw some SFML stuff in a GUI.
I noticed with only Android (Ubuntu it's as expected), textures inside Canvas are rendered upside down.
I am not sure this is about TGUI or SFML though. Do you have any idea ?

[texus]

Are you calling the "display()" function on the canvas when you are done drawing?
Not doing so can have this effect.

If that doesn't solve it then try rendering something directly in SFML with sf::RenderTexture (which canvas uses internally). If that also has the contents flipped then we know that the issue is with SFML.

[Nafffen]

Yep I use display() directly from canvas object
I have a object with :

Code Select Expand

        m_canvas->clear();
        m_sc.get().drawMapOnTarget(m_canvas->getRenderTexture(), m_viewToFocusEntity);
        m_canvas->display();
And another with:

Code Select Expand

    m_canvas->setView(m_view);
    m_canvas->clear();
    m_canvas->draw(m_spriteMiniMap);
    m_canvas->display();
Both are upside down while on Ubuntu it's ok.
Drawing in sf::RenderTexture seems to be as expected

[Nafffen]

I'm sure this is about TGUI now,
and there is also a huge FPS drop while canvas are rendered, I have not digged in into your code, but I understood that Canvas is just a sort of a wrapper around an sf::RenderTexture, with some automatic creation / resizing to fit TGUI size model

[texus]

Resizing the canvas will call "renderTexture.create(newSize)", while "clear", "draw" and "display" are just forwarded to the renderTexture.

The only thing that could be different with using SFML directly is that in order to render the canvas contents to the screen I just access "renderTexture.getTexture()" and render that texture. So maybe that texture is still flipped on Android (i.e. when using OpenGL ES instead of when using desktop OpenGL). I'll try to check that later.

Performance-wise, the slowdown is probably me copying the sf::Texture (that I get with the "renderTexture.getTexture()" call), in the display() function, to a different location so that it works together with the other rendering code.

[texus]

Are you certain that it works with just SFML? Can you try the code from https://github.com/SFML/SFML/issues/2419 ?

[Nafffen]

Yep you are right it's indeed flipped, my bad I should have looked into SFML's github issue (I just looked through forum)
I though SFML was ok because I had several other sf::RenderTexture not upside down.
I don't know where exactly SFML is broken but having a sf::Sprite directly using a sf::RenderTexture seems to be working
Thank you anyway, I'll wait the bug fix
About the performance issue, is there anything I can do to manage it ?

[texus]

I've updated the CanvasSFML class to no longer copy the sf::Texture. This should provide better performance. With some luck it might even affect the upside-down issue.

In the SFML code, I can see a bug in the OpenGL ES implementation when copying the texture (or at least something that looks like a bug on first sight). In GLES, Texture::update is implemented by calling copyToImage() (which is very slow), and in Texture::copyToImage() the m_pixelsFlipped variable isn't accessed if SFML_OPENGL_ES is defined while it is being used when GLES isn't used (i.e. on desktop). So it looks to me like the GLES implementation doesn't properly flip the pixels.

This however doesn't explain the github issue, which has a flipped texture even without any copies. So maybe the issue is still somewhere else. I might look further into the SFML issue later, but that will require some testing with Android so it might take some time.

EDIT: The github issue does contain a copy of sf::Texture, so that is where the issue lies. I tried rendering an sf::RenderTexture on Android without copying the texture and that image indeed isn't flipped.

[Nafffen]

Thank you very much !

[Nafffen]

The upside down issue is no longer here !
+ Better performance