Welcome, Guest. Please login or register. Did you miss your activation email?
Pages: [1]

Author Topic: Texture copy inefficiency  (Read 2661 times)

0 Members and 2 Guests are viewing this topic.

quinor

  • Newbie
  • *
  • Posts: 7
    • View Profile
Texture copy inefficiency
« 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 but it seems outdated as RenderTexture already works on Intel GPUs (I'm using one right now)
« Last Edit: January 10, 2017, 03:44:45 pm by quinor »
Logged

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Texture copy inefficiency
« Reply #1 on: January 10, 2017, 05:17:57 pm »
Logged
Laurent Gomila - SFML developer

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Texture copy inefficiency
« Reply #2 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
Logged
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

quinor

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Texture copy inefficiency
« Reply #3 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!
Logged
Pages: [1]