Enabling/Disabling config file

[Laurent]

I didn't say I understand why I get these results, but UpdatePixels() takes approximatively 15% of the execution time whereas LoadFromPixels() takes about 1-2% (vs 8% with SFML 1.x).

Ah, I thought you were talking about the overall performances. Don't measure single function calls, it doesn't mean anything since they may just enqueue an OpenGL command in the GPU, and the computation time may be delayed to an arbitrary next command.

There are also internal optimizations (lazy updates) in SFML, for example LoadFromPixels don't actually upload the pixels to the graphics card, it is done on the next call to Bind().

So, what about the overall performances of the video player?

[Ceylo]

The overall performance are really worse.

[golgoth]

I also suspect that RGB format takes a significant amount of process... BGR should be used to avoid unnecessary swizzling on the GPU.

[Laurent]

The overall performance are really worse.

Can you give me an example, with numbers?
I should really test it, there's no way it can be worse than SFML 1.

I also suspect that RGB format takes a significant amount of process... BGR should be used to avoid unnecessary swizzling on the GPU.

You mean that the "native" pixel format on the GPU is BGR? How do you know that?
But anyway, here I'm first interested about the differences between SFML 1 and SFML 2, not general optimizations.

[Hiura]

You may want to check if the perf are only worse on OS X because you know...

[Ceylo]

The overall performance are really worse.

Can you give me an example, with numbers?
I should really test it, there's no way it can be worse than SFML 1.

LoadFromPixels() :
- 55 FPS
- 25 images decoded each second
- LoadFromPixels() takes about 1-2% of the execution time
- sf::Sprite::Draw() takes 10% to 17% of the execution time

UpdatePixel(s) :
- 50 FPS
- 25 images decoded each second
- UpdatePixels() takes about 15% of the execution time (meaning the mutex for the sf::Image object is locked for that time)
- sf::Sprite::Draw takes less that 1% of the exec time


But the most weird point is that the image is displayed while it's being updated, even with the locks. This happens with UpdatePixels() only. I don't know whether this is due to the context sharing or something like that... (the image being duplicated from a context to another ?)


Thus the performances look quite similar (you're were right to ask for numbers ), but the movie playback is absolutely not as smooth as with LoadFromPixels().


@Hiura: as for the testing, I would just suggest to try with LoadFromPixels() and with UpdatePixels(), so that other user can check whether this is changing something. I'll post the SFML version independent code as soon as I've something not too dirty.

[golgoth]

You mean that the "native" pixel format on the GPU is BGR? How do you know that?

Storing 8-bit textures in a BGRA layout in system memory and use the GL_BGRA as the external format for textures to avoid swizzling.

http://http.download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf

But anyway, here I'm first interested about the differences between SFML 1 and SFML 2, not general optimizations.

Well, keep that in mind then because this kind of optimization will make SFML from great to kickass.

[Laurent]

Storing 8-bit textures in a BGRA layout in system memory and use the GL_BGRA as the external format for textures to avoid swizzling.

http://http.download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf

I didn't read the document entirely, but it seems that this is true only for nVidia GPUs. I may be true for other vendors as well, but we just don't know.

Well, keep that in mind then because this kind of optimization will make SFML from great to kickass.

I don't think we need this kind of optimization (remember that it's a simple 2D API, not a next-gen 3D engine). The most important things to optimize are:
- number of driver calls (this is really what kills performances in SFML 1)
- static geometry (for example, provide the ability to render a tiled background as 1 VBO rather than N glBegin/glEnd calls)