[nlemoine]

An oblique rotate() on an opaque background leaves a seam of transparent pixels along the edges of the rotated image with the GD driver:

$image = ImageManager::usingDriver(GdDriver::class)->decodePath('tests/resources/test.jpg');
$image->rotate(45, 'ff0000');
// bundled GD: 899 fully transparent pixels, 1086 at 10 degrees
// libgd 2.3.3: 565 partly transparent pixels, 159 fully and 464 partly at 10 degrees

Imagick gives 0. With a white background the seam is there too, it only shows once the image is on something else than white.

imagerotate() filled the new areas with a transparent color, then the modifier drew a transparent cutout polygon on the background canvas and copied the rotated image over it with blending. imagefilledpolygon() does not cover exactly the same pixels as imagerotate(), so along the edges the transparent fill stays inside the polygon.

imagerotate() now gets the background color as fill and the result is copied without blending, so the cutout is gone. On libgd 2.3.3 the edges are also interpolated against the background now, like with Imagick.

Frames with a transparent color are first copied to a truecolor image without one. On libgd 2.3.3, at oblique angles, imagerotate() replaces the pixels of the transparent color with its fill color, so a GIF or indexed PNG would lose its transparency with the new fill.

This also fixes a TypeError on frames with a full 256 color palette: imagecolorallocatealpha() returned false there and it went straight to imagerotate().

Tests cover the seam, a transparent color at an oblique angle and a full palette. Bundled GD leaves the transparent pixels of tile.png and blocks.png at alpha 126 instead of 127 after the rotation (same on develop), so that test counts alpha >= 120.

[olivervogel]

Thanks.