Implement a function that blends two colors encoded with RGB565 using Alpha blending

It's possible to reduce the multiplies from 6 to 2 if you space out the RGB values into 2 32-bit integers before multiplying:

unsigned short blend_rgb565(unsigned short A, unsigned short B, unsigned char Alpha) 
{ 
    unsigned short res = 0; 
    // Alpha converted from [0..255] to [0..31] (8 bit to 5 bit)        
    Alpha = Alpha >> 3;
    // Alpha = (Alpha + (Alpha >> 5)) >> 3; // map from 0-255 to 0-32 (if Alpha is unsigned short or larger)
    
    // Space out A and B from RRRRRGGGGGGBBBBB to 00000RRRRR00000GGGGGG00000BBBBB
    
    // 31 = 11111 binary
    // 63 = 111111 binary
    unsigned int A32 = (unsigned int)A;
    unsigned int A_spaced = A32 & 31; // B
    A_spaced |= (A32 & (63 << 5)) << 5; // G
    A_spaced |= (A32 & (31 << 11)) << 11; // R
    
    unsigned int B32 = (unsigned int)B;
    unsigned int B_spaced = B32 & 31; // B
    B_spaced |= (B32 & (63 << 5)) << 5; // G
    B_spaced |= (B32 & (31 << 11)) << 11; // R
    
    // multiply and add the alpha to give a result RRRRRrrrrrGGGGGGgggggBBBBBbbbbb,
    // where RGB are the most significant bits we want to keep
    unsigned int C_spaced = (A_spaced * Alpha) + (B_spaced * (32 - Alpha));
    
    // remap back to RRRRRGGGGGBBBBB
    res = (unsigned short)(((C_spaced >> 5) & 31) + ((C_spaced >> 10) & (63 << 5)) + ((C_spaced >> 16) & (31 << 11)));
    
    return res; 
} 

You need to profile this to see if it is faster, it assumes that multiplications you save are slower than the extra bit-manipulations you replace them with.

can you please suggest better way wrt less temp variable

There is no advantage to remove temporary variables from the implementation. When you compile with optimizations turned on (e.g. -O2 or /O2) those temp variables will get optimized away.

Two adjustments I would make to your code:

1. Use uint16_t instead of unsigned short. For most platforms, it won't matter since sizeof(uint16_t)==sizeof(unsigned short), but it helps to be definitive.

2. No point in converting alpha from an 8-bit value to a 5-bit value. You'll get better accuracy with blending if you let alpha have the full range

3. Some of your bit-shifting looks weird. It might work. But I use a simpler approach.

Here's an adjustment to your implementation:

#include <stdint.h>

#define MAKE_RGB565(r, g, b) ((r << 11) | (g << 5) | (b))

uint16_t blend_rgb565(uint16_t a, uint16_t b, uint8_t Alpha)
{
    const uint8_t invAlpha = 255 - Alpha;

    uint16_t A_r = a >> 11;
    uint16_t A_g = (a >> 5) & 0x3f;
    uint16_t A_b = a & 0x1f;

    uint16_t B_r = b >> 11;
    uint16_t B_g = (b >> 5) & 0x3f;
    uint16_t B_b = b & 0x1f;

    uint32_t C_r = (A_r * invAlpha + B_r * Alpha) / 255;
    uint32_t C_g = (A_g * invAlpha + B_g * Alpha) / 255;
    uint32_t C_b = (A_b * invAlpha + B_b * Alpha) / 255;

    return MAKE_RGB565(C_r, C_g, C_b);
}

But the bigger issue is that this function works on exactly one one pair of pixel colors. If you are invoking this function across an entire image or pair of images, the overhead of using the function call is going to be a major performance issue - even with compiler optimizations and inlining. So if you are calling this function row x col times, you should probably manually inline the code into your loop that is enumerating over every pixel on an image (or pair of images).

In the same vein as @samgak's answer, you can implement more efficiently on a 64 bits architecture by "post-masking", as follows:

rrrrrggggggbbbbb

Replicate to a long long (by shifting or mapping the long long to four shorts)

---------------- rrrrrggggggbbbbb rrrrrggggggbbbbb rrrrrggggggbbbbb

Mask out the useless bits

---------------- rrrrr----------- -----gggggg----- -----------bbbbb

Multiply by α

-----------rrrrr rrrrr----------- ggggggggggg----- ------bbbbbbbbbb

Mask out the low order bits

-----------rrrrr ---------------- gggggg---------- ------bbbbb-----

Pack

rrrrrgggggbbbbb

Another saving is possible by rewriting

(1 - α) X + α Y

as

X + α (Y - X)

(or X - α (X - Y) to avoid negatives). This spares a multiply (at the expense of a comparison).

Update:

The "saving" above cannot work because the negatives should be handled component-wise.