SFML community forums

Help => General => Topic started by: quinor on January 10, 2017, 03:38:57 pm

Title: Texture copy inefficiency
Post by: quinor on January 10, 2017, 03:38:57 pm

Why sf::Texture copy constructor is implemented by copying onto and from sf::Image? You could copy a texture directly on a GPU, Is there a reason, or just nobody wrote it yet?

EDIT:

I have found https://github.com/SFML/SFML/issues/190 (https://github.com/SFML/SFML/issues/190) but it seems outdated as RenderTexture already works on Intel GPUs (I'm using one right now)

Title: Re: Texture copy inefficiency
Post by: Laurent on January 10, 2017, 05:17:57 pm

https://github.com/SFML/SFML/pull/1119

Title: Texture copy inefficiency
Post by: eXpl0it3r on January 10, 2017, 05:21:30 pm

In most cases you shouldn't be copying textures around. Some have in the past even argued to make sf::Texture non-copyable.
I however don't know why it was initially implemented like that.

There are some possible upcoming changes: https://github.com/SFML/SFML/pull/1119

Title: Re: Texture copy inefficiency
Post by: quinor on January 11, 2017, 12:27:00 am

Thanks, Laurent! I'm looking forward to this.

eXpl0it3r: I am using SFML to do some dirty, nasty image processing stuff. If you really wanna know more ( ;) ) I'm using it as a backend for image processing pipeline library. I may even publish it on forums when it's more finished!