Arguably this is a bug with go's image package and its failure to allow efficient blitting implementations to/from non-builtin image types (BGRA in our case). Anyway, the current implementation of CopyRGBA is not useful when dealing with images whose top-left bounding point is not image.ZP.
ie. the screen's image has bounds (0,0)-(300,300). centre has bounds (50,50)-(250,250). But the part of the window that actually gets drawn red is (100,100)-(250,250) - there's an extra translation going on.
This PR causes the area (50,50)-(250,250) to be drawn red (tested on linux only). It shouldn't change the results for images that are anchored on image.ZP.
Arguably this is a bug with go's image package and its failure to allow efficient blitting implementations to/from non-builtin image types (BGRA in our case). Anyway, the current implementation of CopyRGBA is not useful when dealing with images whose top-left bounding point is not image.ZP.
The following code demonstrates the issue:
ie. the screen's image has bounds (0,0)-(300,300). centre has bounds (50,50)-(250,250). But the part of the window that actually gets drawn red is (100,100)-(250,250) - there's an extra translation going on.
This PR causes the area (50,50)-(250,250) to be drawn red (tested on linux only). It shouldn't change the results for images that are anchored on image.ZP.