The Transcode is very slow, why ?

This topic contains 2 replies, has 2 voices, and was last updated by  Tobias Hector 3 years, 11 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #31533

    liumazi
    Member

    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 ?

    #38183

    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

    #38184

    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

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.