Based on my experience with GapiDraw 3.6 and AlphaBlt() and AlphaBltFast(), the RGB value expected is in its full value with not Alpha-premultiplied RGB.
However, one very popular optimization technique is premultiplying RGB by its Alpha value and thus reducing one multiplication per each pixel during rendering semi-transparent pixels. Let me explain:
Rendering sprites with non Alpha-premultipied RGB(this is used by AlphaBlt() and AlphaBltFast()):
FinalRGB = RGB * Alpha + (1 - Alpha)*Background;
If we use Alpha-premultiplied RGB (.PNG files support this), the final semi-transparent pixels could be rendered as follows:
FinalRGB = RGB + (1-Alpha)*Background;
As far as I know, all 3D and 2D graphics packages support generating Alpha-premultiplied RGB(that is ready for compositing). Therefore, is there any chance, that in the following release of GapiDraw Alpha-premultiplied RGB would be supported by AlphaBlt() and AlphaBltFast()? This could be easily accomplished by adding a flag to every function, that woud specify whether Alpha-premultiplied RGB is used.
It would not really be a lot of work, and would significantly speed up alpha computations - a great optimization technique.