Andreas Raab wrote:
so it trys to install a color map from 32-bit regardless the actuall depth of the source. Why?
For precisely the reason you notice. The color map ensures that the averaged pixel can be mapped from the 32bit RGBA representation into whatever the destination depth is. Internally, when cellSize>1 we always treat the input as 32bit since we know that WarpBlt will average that way. But why this isn't working for 16->32 is a good question...
Okay, found it. The VM will substitute a standard color conversion if no colorMap is given and since Color>>colorMapIfNeededFrom:to: will not create an explicit color map for 32->32 bit conversions, the VM will use a color map from the sourceForm's depth (16) to the destForm's depth (32). Which, for WarpBlt w/ smoothing is just plain wrong.
Fix attached - it simply works around the problem by installing an appropriate (no-op) color map for 32->32 conversions if necessary.
Cheers, - Andreas