Ah, ImageToBlob() into newFromData Win32::GUI::DIBitmap was what I was
looking for... that saves some time with intermediate disk files
saving/loading.
The memory leak in AlphaCopyToDC in 1.03_4 is fixed, so I do suggest
updating if you use this call.
I removed my flickering by "double-buffering" to a compatible DC and
AlphaCopyToDC into that, then BitBlt the DC back into the window, but
then I am updating the whole window area, copying multiple images into
the window on each paint refresh, and it looked terrible when using
AlphaCopyToDC directly into the window's DC.
Steve
Robert May wrote:
OK, so I caught the bug too. I've added the 'coalesce()' call that
Steve found, and am handling different delays for different frames. By
using the Win32::GUI::DIBitmap AlphaCopyToDC method for drawing into the
DC directly it copes with transparent colours, but as a result the
drawing is a bit slow (and a bit flickery).
# Load the frames, get the delay and convert frames to
Win32::GUI::DIBitmap DIBs
sub LoadDIBs {
my $file = shift;
my (@frames, @delay_dibs);
# Create new Image::Magick object
my $image = Image::Magick->new();
# Load the image(s) from file
#TODO: error checking
$image->Read($file);
# Coalesce multiple images so that each frame is a whole image
$image->Coalesce();
# Convert all ImageMagick frames to raw gif data
push @frames, $image->[$_]->ImageToBlob() for (0 .. $#$image);
# Get delay and Create DIBitmap objects for each frame
for (0 .. $#$image) {
# Get the frame delay.
# convert delay from 1/100th seconds to milliseconds
push @delay_dibs, $image->[$_]->Get('delay') * 10;
# convert frame to DIB
push @delay_dibs, Win32::GUI::DIBitmap->newFromData($frames[$_]);
}
return @delay_dibs;
}