That seems to be a bug in the CopyToGD() method.
It can load the png you write to disk without error.
It can also successfully create a GD image from the data returned by the SaveToData() method:
use Win32::API;
use Win32::GUI::DIBitmap;
use GD;
$GetDC = new Win32::API('user32','GetDC',['N'],'N');
my $dc = $GetDC->Call(0);
my $dib = newFromDC Win32::GUI::DIBitmap ($dc);
$dib->SaveToFile("DIBitmap.png");
#my $GDimage = GD::Image->newFromPng( "DIBitmap.png", 1 );
my $mem = $dib->SaveToData( Win32::GUI::DIBitmap::GetFIFFromFormat( 'P
+NG' ) );
my $GDimage = GD::Image->newFromPngData( $mem, 1 );
open (DISPLAY, ">GD.png");
binmode DISPLAY;
print DISPLAY $GDimage->png;
close (DISPLAY);
You should raise a bug report with the author.
The problem probably stems from the mismatch between the version of the GDImageStruct used by DIBitmap & the version used by the latest GD incarnations:
Compare: (<)C:\test\GDstruct.gd (3146 bytes)
with: (>)C:\test\GDstruct.dib (3124 bytes)
63,67c63
< /* There should NEVER BE ACCESSOR MACROS FOR ITEMS BELOW HERE, s
+o this
< part of the structure can be safely changed in new releases.
+*/
<
< /* 2.0.12: anti-aliased globals. 2.0.26: just a few vestiges aft
+er
< switching to the fast, memory-cheap implementation from PHP-gd
+. */
---
> /* 2.0.12: anti-aliased globals */
71a67,78
> unsigned char **AA_opacity;
> int AA_polygon;
> /* Stored and pre-computed variables for determining the perpend
+icular
> distance from a point to the anti-aliased line being drawn: *
+/
> int AAL_x1;
> int AAL_y1;
> int AAL_x2;
> int AAL_y2;
> int AAL_Bx_Ax;
> int AAL_By_Ay;
> int AAL_LAB_2;
> float AAL_LAB;
79,82d87
<
< /* 2.1.0: allows to specify resolution in dpi */
< unsigned int res_x;
< unsigned int res_y;
84,85d88
<
<
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|