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;
}


Reply via email to