Problems with Resizing RenderWindow/RenderTexture

[Outstream]

I am drawing to a RenderTexture which is then drawn to a RenderWindow. I am attempting to resize them both without scaling. When the window is resized, I create a new view and apply it to this window. This works great until I try to resize the RenderTexture as well.

This is the result if I don't resize the RenderTexture (the green is the RenderWindow)

But when I resize the RenderTexture (by calling create(width, height) again), I get weird results, UNLESS I recreate the window (which I would very much like to avoid).

 The result is either the texture doesn't appear, the texture flickers, or (this is odd) The texture's y value matches the height difference, and the green (window) doesn't render at all and is transparent.

The drawing is handled on a separate thread from the resizing, but the drawing thread is locked during the resize.

[eXpl0it3r]

Don't use multi threading for rendering and updating, it's simply not worth the effort and will be the source of many issues.

I assume you do call clear, draw display on the render texture as well, right?

Without a complete and minimal example that reproduces the issue, we can't really help you further.

[Outstream]

Don't use multi threading for rendering and updating, it's simply not worth the effort and will be the source of many issues.

I assume you do call clear, draw display on the render texture as well, right?

Without a complete and minimal example that reproduces the issue, we can't really help you further.

Yeah, I call clear and display on both. I'll try to reproduce an example. In the mean time, could you tell me if it is possible to resize a window without stretching and then use it normally?

[eXpl0it3r]

Not exactly sure what you mean by "resize a window without stretching"?

You can change the size of a window by calling setSize().
The view will then "stretch" with the window, which may lead to distortion and might not be what you want. The solution is shown in the official tutorial.

Maybe try to explain what your final goal is and we might be able to help you figure out what you need to do.

[Outstream]

That is what I meant by not stretching, which I know is possible. What I was trying to ask is if that method will achieve the same effect as recreating the window.

I am trying to create a user friendly GUI library with SFML as the base. I would like it to be threaded as it would be more user-friendly if the library handled the framerate (when the draw function is called) so it only updates when needed.

As I'm typing this, I realize the user could call the draw function at their own framerate, and the library can decide if it actually needs an update.

I've believe I've thought of a few better options, but I will keep trying to recreate my problem on a small scale if you don't mind coming back to this post in the future

One more question though, theoretically is there any reason that this wouldn't work: if all of the SFML objects are created (and drawn on) on one thread (that isn't the main thread) and are then only modified through requests from another thread. Basically, can SFML work entirely on a secondary thread?

Thanks for the help, btw!

[Outstream]

That is what I meant by not stretching. What I was trying to ask is if that method will achieve the same effect as recreating the window.

I am trying to create a user friendly GUI library with SFML as the base. I would like it to be threaded as it would be more user-friendly if the library handled the framerate (when the draw function is called) so it only updates when needed.

As I'm typing this, I realize the user could call the draw function at their own framerate, and the library can decide if it actually needs an update.

I've believe I've thought of a few better options, but I will keep trying to recreate my problem on a small scale if you don't mind coming back to this post in the future

One more question though, theoretically is there any reason that this wouldn't work: if all of the SFML objects are created (and drawn on) on one thread (that isn't the main thread) and are then only modified through requests from another thread. Basically, can SFML work entirely on a secondary thread?

Thanks for the help, btw!