Texture Update memory wierdness

[slotdev]

Hi

I've got a strange bug where when I call "update" on a texture, with a pointer to my pixel buffer, then draw the texture, it displays correctly on the target window but *also* displays in stretched & smeared form on another window, positioned directly below the main (target) window.

It seems like a memory problem, or as if the update function is just running over the end of something....

Does anyone have any ideas??

Thanks
Ed

[Nexus]

What is this other window? Might it be that it doesn't correctly clear and display? For example GUI frameworks render upon events, not constantly. But they usually re-render when getting focus again, to avoid such issues.

[slotdev]

Nexus, its just another SFML window, which is cleared & redrawn every frame in time with the main window.


More background: I use Berkelium, an "off screen" web browser which copies pixel data to a buffer, and then posts a callback telling us the buffer is updated. I then copy this buffer to the SFML texture and display on screen. This works 100% OK but I just get this strange memory problem.

[Laurent]

Would you be able to reproduce the problem in a small and complete example? For example, first remove Berkelium and use a hard-coded array of black pixels (for example). Then see if you can simplify further, until you get something that we can test.

[slotdev]

I will do - but more testing with a newer version of SFML does not show this problem, so for this (old) project I am working on, I have to check the difference between the two SFML versions.

EDIT: Do you remember why this line was added (Texture::Update line 1252)

// Make sure that the current texture binding will be preserved
        priv::TextureSaver save;

?

[Laurent]

Yes. It's to preserve the current texture binding in case the user calls Texture::update in the middle of its own OpenGL calls involving another texture.