readPixels is slow due to naive BGRA to RGBA conversion

[GoogleCodeExporter]

Using readPixels to read a large texture is very slow. This greatly impacts 
using the GPU for computation in WebGL (our use case is image editing). It 
appears that ANGLE has a fast path if both the source and target data are BGRA 
but we can't use this because WebGL doesn't support BGRA. It also appears that 
ANGLE doesn't have a fast path for the important case when the source is BGRA 
and the target is RGBA. This causes readPixels to convert from unsigned bytes 
to floats and back to unsigned bytes to perform a simple byte swap.

Original issue reported on code.google.com by evan....@gmail.com on 4 Mar 2013 at 8:27

[GoogleCodeExporter]

The Direct3D 11 back-end uses RGBA formats internally, so readPixels should be 
faster once that path is enabled.

Obviously the Direct3D 9 path could also be optimized significantly. The code 
in Image::loadRGBAUByteDataToBGRASSE2 could form a good basis for that.

Original comment by nicolas....@gmail.com on 5 Mar 2013 at 2:37

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I've submitted a basic patch at https://codereview.appspot.com/7466044/ that 
gives a 5x speedup just using bit shifts. I noticed the code in 
Image::loadRGBAUByteDataToBGRASSE2 when I was writing the patch but I didn't 
notice a significant speedup over bit shifts when I tried it. Maybe memory 
bandwidth is the main bottleneck? Of course a much better fix would be to allow 
BGRA in WebGL (10x speedup instead of 5x) but that's a different discussion.

Original comment by evan....@gmail.com on 5 Mar 2013 at 4:54

[GoogleCodeExporter]

Patch is committed in r1999

Original comment by shannon....@gtempaccount.com on 19 Mar 2013 at 5:31

• Changed state: Fixed