The Transcode is very slow, why ?

PowerVR Insider
1

extern “C” DLL_EXPORT int32 ConvBitmap32ToPVR(const uint32 Width, const uint32 Height, const uint64 DstFmt, const void* SrcData, void** DstData)

{

// Create the header. Format is bgra8888

CPVRTextureHeader cHeader(0x0808080861726762, Height, Width);



// Create the image.

CPVRTexture cTexture(cHeader, SrcData);



// Transcode to DstFmt

Transcode(cTexture, DstFmt, ePVRTVarTypeUnsignedByteNorm, ePVRTCSpacelRGB);



// Save the file

//cTexture.saveFile(“D:\liumazi.pvr”);



// Get Data Size

int DstSize = cTexture.getDataSize();

if (DstSize <= 0) return DstSize;



// Copy the Data

*DstData = malloc(DstSize);

memcpy(*DstData, cTexture.getDataPtr(), DstSize);



return DstSize;

}





I found the function "Transcode " is very very very slow …

I found that the program has been to create threads in frequently, Even just convert one picture



How should I do to make it faster ?

2

Hi Liumazi,



The transcode function is designed to be extraordinarily flexible in terms of format support - the same code supports rgba8888, rgba32323232 and rgb727, etc. This flexibility unfortunately comes at a performance cost. There are efforts ongoing to attempt to optimise the code, but there’s no easy fix here.



However, you can increase the performance of this operation with a slight tweak to the code. If you declare the header as rgba8888, then use the function “CopyChannels” instead, to switch the red and blue channels, this should perform faster than doing a full blown transcode.



Regards,

Tobias

3

Hi Liumazi,



I think I may have read your post wrong - for some reason I read it as you were trying to convert to RGBA8888, but on a re-read it sounds like you’re trying to convert to PVRTC?



This being the case, I’d still possibly do the above step for PVRTC data, as the transcode has to turn it into RGBA8888 data regardless, but it’s unlikely to make an enormous difference. You’ll still have to transcode it to the PVRTC format afterwards. Sorry for any confusion!



PVRTC compression is naturally slow because of the algorithmic complexity of the format. Unlike traditional block-based schemes, PVRTC compresses across neighbouring regions, which makes the search space for the best result that much higher, resulting in a long compression time.



Regards,

Tobias