Updating texture data, very slow on Intel graphics.

[Zapfyr]

Hi,

I have been playing around with the Intel NUC (DC3217IYE to be specific) which uses Intel HD 4000 graphics. And for some reason updating a sf::Texture is painfully slow compared to Nvidia or AMD graphics. After some googling I found these:

http://www.opengl.org/discussion_boards/showthread.php/175501-glTexSubImage-still-unacceptable-slow
http://forums.inside3d.com/viewtopic.php?t=2465

This is the code that updates the actual texture in SFML:

glTexSubImage2D(GL_TEXTURE_2D, 0, x, y, width, height, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
 

If it were to be changed to:

glTexSubImage2D(GL_TEXTURE_2D, 0, x, y, width, height, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, pixels);
 

it would improve performance a lot (on, some, Intel graphics). Now I do not exactly know if some thing else have to be changed to make this work, I just though I should tell you about my findings.

I have tried this when streaming video to a texture using GStreamer, so I know that it makes a LOT of difference on Intel hardware and that it does not impact performance on Nvidia or AMD hardware. The streaming has been done with both PBOs and just a simple glTexSubImage2D call and both methods become significantly faster when using GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV.

// Zap

[Laurent]

The problem is that SFML uses RGBA pixels, not BGRA or ARGB. It would really break the API too much to switch to BGRA.

But thanks for the feedback, I didn't know that graphics cards (and especially Intel ones) were optimized for BGRA.

[binary1248]

http://www.opengl.org/wiki/Common_Mistakes#Slow_pixel_transfer_performance

It seems some parties can be quite picky (insert big software company everybody knows here).

[Zapfyr]

The problem is that SFML uses RGBA pixels, not BGRA or ARGB. It would really break the API too much to switch to BGRA.

Too bad. :/

This problem can be solved with a very simple fragment shader that swaps (swizzling) the components, however it feels very much like an ugly hack.

As a side note, sfeMovie becomes next to useless (as it uses the update function in sf::Texture) on Intel hardware because of this issue.

// Zap