RenderTexture passes its texture ovenership to Texture

[BaneTrapper]

Hello.
Id like to request a possibility of sf::RenderTexture swapping ownership of its texture with sf::Texture.
Reasons being,

Code: [Select]

std::cout << sizeof(sf::RenderTexture) << std::endl;//488
std::cout << sizeof(sf::Texture) << std::endl;//32
My thought are that RenderTexture was supposed to be used as a drawing board and sf::Texture would be the paper that you actually draw on.

Related to topics:
http://en.sfml-dev.org/forums/index.php?topic=16178.0
http://en.sfml-dev.org/forums/index.php?topic=16174.0
Is it possible to expect such a feature?

[Stauricus]

what do you mean by 'swapping ownership'?
and i think sf::Texture would be the drawing itself, not a paper where you draw.

[Jesper Juhl]

Copying (moving) a RenderTexture to a Texture is not enough?
Not sure I understand what you need/want that cannot already be done..

[Laurent]

Would be nice to explain why you want such a feature.

[BaneTrapper]

Copying (moving) a RenderTexture to a Texture is not enough?
Not sure I understand what you need/want that cannot already be done..

Moving renderTexture to texture, is that possible? i tested, and failed to accomplish that.
Example please.

Would be nice to explain why you want such a feature.

It looks like the "feature already exists" i just failed to see it.

what do you mean by 'swapping ownership'?
and i think sf::Texture would be the drawing itself, not a paper where you draw.

I mean that i cannot extract the texture from sf::RenderWindow to sf::Texture.
The sf::RenderTexture has to have the texture pointer in GPU, texture has none and is in "invalid" state by default afaik.
Setting sf::Texture texture to sf::RenderTexture texture (meaning now they share it)
Then sf::RenderTexture texture to nothing. Meaning we swapped ownership of texture from sf::RenderTexture to sf::Texture without having to copy the texture around.

[Jesper Juhl]

Copying is posible and if SFML 3.0 adds a move constructor and move assignment operator then we'll be all set for moving
But (besides performance implications) why is copying not enough? What super critical/performances sensitive operation are you doing?

[Laurent]

Copying is posible and if SFML 3.0 adds a move constructor and move assignment operator then we'll be all set for moving

You can't move a const texture.

[Jesper Juhl]

Argh. My bad. I'm an idiot. I forgot that it is const.
Sorry.

[BaneTrapper]

I no longer require such feature, tho having it would be improvement to performance.

[Tank]

Also, copying (or even moving) an internally managed resource out of sf::RenderWindow sounds like a really bad idea. Instead I'd suggest something like this:

sf::Texture texture;
sf::RenderTexture renderTexture(texture);

[Hapax]

sf::RenderTexture renderTexture(texture);

What does this do? 

[zsbzsb]

Isn't it clear?

The render texture will instead of creating its own internal texture would use the texture passed in the overloaded constructor as the target for draw calls.

[Laurent]

This would be almost equivalent to the current code (the only difference is that you can change the texture properties before passing it to the RenderTexture). A more useful version would be a setTexture function, so that you can use the same RenderTexture to draw on multiple textures. But I wonder what kind of problem this would solve...

[Hapax]

Isn't it clear?

It is not clear. It looks obvious, sure, but I wouldn't want to use it on an assumption.
I did try to find information on this in the documentation but, alas, I could not find any.
Does the render texture make a copy of the texture or point to the actual one?

[binary1248]

Does the render texture make a copy of the texture or point to the actual one?

I take from the discussion that it will simply point to the actual one, hence the equivalence to a .setTexture() method that is already part of some other classes. I can already see all the "white square RenderTexture" threads rolling in .