efficient method for manipulating pixel data of surfaces/images

[comme]

Hi,
I want to draw directly to the renderwindow, and I see I can use sprites, images, textures, that sfml displays on the screen.
I am trying to avoid the overhead of copying megabytes of screen arrays around, my application is performance critical.
Is there any particular method/trick to manipulate the pixels or do I have to use update() (I remember the developer of this library saying years ago that it does a full copy)

Thanks for any input

[Hapax]

Oo, sounds really important!

I'd like to help but I can't do so for two reasons:
1) other people will be able to help a lot better than I,
2) I have no idea what you're trying to achieve.

[eXpl0it3r]

If your application is performance critical use shaders, really!
If you don't use shaders, your application can't be performance critical, or you've left out the important information. You're then left with keeping a copy of sf::Image or better yet a std::vector<sf::Unit8> on the RAM, doing your pixel manipulation and then calling update() on the sf::Texture.

[comme]

If your application is performance critical use shaders, really!
If you don't use shaders, your application can't be performance critical, or you've left out the important information. You're then left with keeping a copy of sf::Image or better yet a std::vector<sf::Unit8> on the RAM, doing your pixel manipulation and then calling update() on the sf::Texture.

ah well. Thanks.

I need the best possible framerate I can get for my software rendering project.
I remember using sdl years ago and getting around 8000fps writing (almost) directly to vram, same with directdraw, but with update() I count very few fps....

[Jesper Juhl]

I don't know what you want to do or why, but I fail to see how triple digit (or more) FPS can be relevant. The human eye is not even close to being able to perceive that...

[binary1248]

Hmm... let's do some maths here...

Assume each pixel in the VRAM framebuffer is composed of a 24-bit RGB value.
At 8000 FPS, that would be...

8000 x 24 = 192000 bits per pixel per second

Say you had a more or less simple platformer with a scrolling background. Because you cannot assume that pixels stay the same from frame to frame, exploiting the temporal coherence of each frame (as with MPEG) isn't an option and you would have to end up transferring the whole screen's worth of data every frame.

Assume that the application was run in a 800x600 window. That is 480000 pixels to be updated every frame. This means that 92160000000 bits or 11.52 GB would have to be transferred every second from host to VRAM.

I'm interested, were you part of a special research group that had early access to 16-lane PCIe 3.0 GPUs back then? Because I don't see any other way a commercially produced GPU would be able to handle such high data transfer rates...

This was all of course based on a conservative estimate. The true values could be much larger .

Or... one of the assumptions is simply not true... I wonder which one it could be...