Nevermind, it was a misunderstanding of the API. The x and y values on the update functions describe the offsets and not the size or similar. As such they need to be 0.
Changing my code to the follow makes it run without issues.
#include <SFML/Graphics.h>int main
(){ sfVideoMode mode
= {800, 600, 32}; sfRenderWindow
* window
; sfTexture
* texture
; sfSprite
* sprite
; sfImage
* image
; sfEvent event
; window
= sfRenderWindow_create
(mode
, "SFML window", sfResize
| sfClose
, NULL
); if (!window
) return -1; texture
= sfTexture_createFromFile
("A.png", NULL
); if (!texture
) return -1; sprite
= sfSprite_create
(); sfSprite_setTexture
(sprite
, texture
, sfTrue
); image
= sfImage_createFromFile
("B.png"); if (!image
) return -1; while (sfRenderWindow_isOpen
(window
)) { while (sfRenderWindow_pollEvent
(window
, &event
)) { if (event.
type == sfEvtClosed
) sfRenderWindow_close
(window
); else if (event.
type == sfEvtMouseButtonPressed
) { printf("MouseButton Pressed - updateFromImage\n"); sfTexture_updateFromImage
(texture
, image
, 0, 0); } else if (event.
type == sfEvtKeyPressed
) { printf("Key Pressed - updateFromPixels\n"); sfTexture_updateFromPixels
(texture
, sfImage_getPixelsPtr
(image
), 64, 64, 0, 0); } } sfRenderWindow_clear
(window
, sfBlack
); sfRenderWindow_drawSprite
(window
, sprite
, NULL
); sfRenderWindow_display
(window
); } sfImage_destroy
(image
); sfSprite_destroy
(sprite
); sfTexture_destroy
(texture
); sfRenderWindow_destroy
(window
); return 0;} So it's not an issue with CSFML as far as I can tell.
So now I am wondering: is it possible that the update-method from Texture fails when it is called from a thread that is not the main-thread? I can't recall having read about it in the documentation...
The update will call OpenGL functions, with them no being run in the same thread, it's very well possible that issues can arise. You'd have to activate the thread's context before using anything in that thread and since OpenGL isn't multi-threaded, the OpenGL commands will be put into the queue and executed maybe slightly later.
For animation timing, you may want to go the non timer event route and use some clock to track the passed time etc.
It will most likely also be more precise as you're not relying on OS callbacks/interrupts which need to go through the event pump and precise timers (but I might also be wrong on this one).