Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Updating texture of sprite.  (Read 16483 times)

0 Members and 3 Guests are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11034
    • View Profile
    • development blog
    • Email
Re: Updating texture of sprite.
« Reply #15 on: September 14, 2017, 03:34:37 pm »
You should never have to explicitely call w.SetActive, SFML is supposed to handle context switches in threads automatically (in this use case, at least).
I don't think this is the case anymore.
We can't have both worlds, where everything happens magically, but everyone can still control things.

Since multi-threaded rendering is a more advanced topic, we've basically opted for giving the user more control and afaik binary1248 refactored it, so that you need to handle context individually on each thread. Nothing is "assumed".
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Updating texture of sprite.
« Reply #16 on: September 14, 2017, 07:07:50 pm »
From the current source code, it really seems that we still activate a default context if none is active in the current thread.

See:
https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Texture.cpp#L418
https://github.com/SFML/SFML/blob/master/src/SFML/Window/GlContext.cpp#L170

Moreover, an OpenGL error would be printed to the console if there were no active OpenGL context for Texture::update.
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Updating texture of sprite.
« Reply #17 on: September 14, 2017, 10:27:37 pm »
SFML resources still "take care of themselves". Any SFML resource requiring an OpenGL context to be active will activate some implementation defined context and deactivate it once the operation is done. RenderTargets on the other hand need a bit more manual work to be done when multi-threading. Because SFML can't assume which thread is currently drawing to a RenderTarget the user will have to explicitly make sure it is deactivated on all other threads before activating it in a specific thread. Only the user can know when it is safe to do so so this is something SFML can't automatically do.

When it comes to raw OpenGL, the situation has changed from before the context changes. Where one could assume that SFML would leave a residual context active after any operation, one can't assume this is the case now. The "a context is always active" invariant was never formally defined anywhere before anyway and users just figured that part out on their own. This is the reason why some were surprised when this undocumented behaviour was changed.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

 

anything