RenderTexture passes its texture ovenership to Texture

[Laurent]

To me, we don't need such a feature anyway and this discussion can thus be closed.

[binary1248]

Well, it depends really. If people, for whatever reason, want to use a single RenderTexture to draw to multiple texture destinations every frame because they only need a single "drawer" RenderTexture, then it makes sense to enable them to do so. Some time not so long ago, I even recommended reusing RenderTextures because it minimizes the number of contexts floating around, and in the end, it really doesn't make sense to store multiple of them if you can reuse the same one. OpenGL FBOs were designed to be easy to swap out attachments for for this purpose, so I don't see why we shouldn't pass that power on to SFML's users as well.

[Laurent]

If people, for whatever reason, want to use a single RenderTexture to draw to multiple texture destinations every frame because they only need a single "drawer" RenderTexture, [...]

Then let's find a relevant use case for this before deciding anything. You know the SFML philosophy, "don't do it if nobody needs it"

[Hapax]

I thought the philosophy was "don't do it if only one person needs it". 

A possible scenario that someone may possibly want to do is a group of television screens 

EDIT: If this rendertexture(texture) thing works, I guess that would do that.

[Laurent]

I thought the philosophy was "don't do it if only one person needs it".

It has slightly evolved since then

A possible scenario that someone may possibly want to do is a group of television screens

I'd like answers without the words "possible", "may", "possibly", etc. Real use cases please.

If this rendertexture(texture) thing works, I guess that would do that.

Such a thing doesn't exist, it was just an idea. And no, it wouldn't do that since the RenderTexture would be tied to a unique Texture instance.

[Hapax]

It has slightly evolved since then

Good to know 

I'd like answers without the words "possible", "may", "possibly", etc. Real use cases please.

This means that you are waiting for someone to require it for a project before considering implementing it. In which case, SFML will not be able to provide for the requirement of their project. The "possibly" stuff is a way of saying that these things could happen and is one example of something people may require. If someone said that they were going to do the thing that I just suggested as a possibility, does that make it a real use case?

the RenderTexture would be tied to a unique Texture instance.

Tied? Does this mean that the texture cannot be used as a texture for anything else? 

[Laurent]

This means that you are waiting for someone to require it for a project before considering implementing it. In which case, SFML will not be able to provide for the requirement of their project. The "possibly" stuff is a way of saying that these things could happen and is one example of something people may require. If someone said that they were going to do the thing that I just suggested as a possibility, does that make it a real use case?

Since this feature would be an optimization only, it won't block anyone. So yes, I'd really like to know if someone really needs this before doing it. If nobody cares, there's probably no point making the code more complicated.

Tied? Does this mean that the texture cannot be used as a texture for anything else?

No. I just said that since you pass the texture to the constructor, you won't be able to change it afterwards. So you end up with 1 RenderTexture = 1 Texture, which is exactly what the current API does. No point.

[Tank]

Of course it shouldn't be fixed, that's why I wrote "like this".

[Hapax]

If nobody cares, there's probably no point making the code more complicated.

I didn't realise that it would, I'm sorry.

I just said...

I wasn't trying to trick you or question whether you stated anything correctly or anything. I genuinely just wanted to know. Sorry if you understood it that way