Pixel Buffer Objects support in SFML2

[pierotofy]

Greetings

In my program I have a lot of image data coming in (you can think of the data as the frames of a movie streaming) and I'm currently using the update function of the Texture class to refresh the texture on screen, as follow:

// sf::Texture *texture = ....
void onFrameAvailable(char *bitmap_in){
texture->update((sf::Uint8 *)bitmap_in, textureWidth, textureHeight, 0, 0);
}
 

Which works, but I noticed that as I increase the size of the texture the performance drops dramatically (for obvious reasons).

I read in a few places that Pixel Buffer Objects could be used to create spaces of shared memory between the CPU and the GPU (if I understood correctly). Right now I'm constantly copying data from the CPU to the GPU when calling the update function, maybe if I simply setup a space in memory where I can update my image data and tell OpenGL to use that space in memory to display my texture things would be faster.

Any suggestions? Ideas?

[eigenbom]

That sounds about right. Afaik SFML doesn't have this functionality, so you'll have to switch out to OpenGL commands. This slideshow seems to describe the process in detail.

[Laurent]

It can be implemented but I'm afraid it would complicate the API too much.

[Canadadry]

Hi,
I'm finding this function quite interesting too. And I wonder if we could have at least virtual functions to let us implement it ?
Thanks.

[eXpl0it3r]

SFML is open source and uses the zlib license, which means you can do whatever you want with it, so feel free to fork SFML and implement it on your own.

[Canadadry]

I've already done that. But I don't want to be cut off the official sfml, it's to much work for a so small feature. I rather like use an ugly trick (like "#define private public") than fork SFML. But that's not the point here. 

[eXpl0it3r]

Well Laurent won't implement an ugly trick, so you don't have to do anything.
If he thinks it's a good idea to implement, he'll do it for SFML 2.x, otherwise you'll have to do it on your own.

[Laurent]

It would be nice to share your implementation, as well as performances comparisons between PBO and no-PBO.

[Canadadry]

I'll try to write something clear to show you. For performance, you could watch that http://www.songho.ca/opengl/gl_pbo.html. For me PBO run 6 times faster than glTexSubImage2D. He's uploading a texture (1024x1024 as RGBA) with pbo which take less than a millisec (and 6ms without).

For The API I guess an UpdatableTexture with the exact same interface as the current Texture would fit perfectly. It just need a create and an update function to work.