GDI+ renders to 32bpp DIB in premultiplied pixels. When using GDI+ one does not need to be concerned with premultiplied or not. Only real exception is when extracting data from the GDI+ image, one must choose which color format they want, other than that, it isn't a concern for nearly all of the GDI+ calls.
Edited: A downside here is that once you render to GDI DC, you can never get true RGBA back from the DC, it will always be pRGBA.
As a simple test, I used GdipGraphicsClear on a new DIB passing a transparent white (&H00FFFFFF) and then retrieving the color from the DIB, what I got back was not &H00FFFFFF, it was &H00000000 (black) because of pre-multiplication; any fully transparent color becomes black.
The GDIpImage class does all the rendering in its Render function. Before rendering, it is just a matter of setting up the device context description beforehand. You tell GDI+ what smoothing/anti-aliasing quality you want to render in, what scale to render in, what angle to render at, and several other options. Once you define that, then you tell GDI+ to render & it does all the pixel X,Y translations while it renders. Rotation with GDI+ is different. You don't manipulate pixels. Rather you tell GDI+ that the device context is rotated and GDI+ translates the pixels as it draws. I have in my possession very fast VB-only rotation code, but it is not faster than GDI+. I also have bilinear and bicubic Vb-only algorithms; again slower than GDI+
I think the old fashioned code is good to have for basic understanding of how rotation, scaling, etc, etc work. But I don't use any longer for reasons noted in previous post #77.