To add to confusion -- even shorter code to generate transparent PNG (but not GIF) would be

my $image = GD::Image->new(1, 1);
$image->colorAllocateAlpha(0, 0, 0, 127);
# output follows
[download]

(return value ignored; no call to bot's beloved transparent)

I am not an expert. For palette-based images, the colorAllocate (colorAllocateAlpha) would return palette entry index just added; -1 for failure (palette full?). For "TrueColor" images, these methods don't add anything anywhere (perhaps not quite so... I'll elaborate later if time's left). They are convenient shortcuts for pack/unpack as I see it:

unpack 'V', pack 'C4', 0, 0, 0, 127
[download]

which is... two gigabytes :) ? Because painting methods (such as setPixel) expect just an integer for color, be it palette index or 32-bit integer, where appropriate.

GD creates images with zeroes-filled canvas. For palette-based images, it means that 1st palette entry (non-existent at the time i.e. yet to be added) would define "background". PNG palette can be thought of as "RGBA", though it's indirectly so (irrelevant detail): axillary tRNS chunk controls entries' partial transparency; it doesn't have to cover all palette; degenerate case would be binary GIF transparency; hence no real necessity to call transparent even if palette-based.

0 for alpha usually designates full transparency. GD encodes as opposite, internally (not in PNG output, of course). 0 of newly created "TrueColor" canvas means "opaque". The '127' is fully transparent. And by the way, it follows that opening "TrueColor" semitransparent PNG and immediately saving leads to loss of information. I only vaguely remember the reason why 7-bit depth alpha-channel limit exists in GD. The "TrueColor" support is later addition on top of existing data-structures; backward compatibility compromise or something similar.

To directly address another your question, 0-filled (i.e opaque) "TrueColor" canvas just has to be painted (e.g. setPixel) with transparent color (i.e. 32-bit integer with non-zero byte at big(? confused myself at this late time)-end byte) to introduce transparency. The transparent call would not change anything here.