ID: 39353
Updated by: pajoye@php.net
Reported By: seth at pricepages dot org
Status: Bogus
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
It is in there since a long times and all the new functions (that I
added for example) do not have this obvious problem and access the
right buffer directly.
As I agree about the lack of performance of the GD library in some
areas, I do not see the points to criticize it as you did in this
report. Especially not when you get help and support. It is also very
easy to spot problems in other codes without actually taking care about
the reasoning or the history.
Previous Comments:
------------------------------------------------------------------------
[2006-11-04 19:53:23] seth at pricepages dot org
> For example?
gdImageCopyResized() in our example (palette -> true color,
no alpha blending) requires 11+ branches and 3 function
calls per input pixel. There is another function call and 4+
branches per output pixel. I'm skipping a good number of
branches created by the short-circuiting in each of those 15
if statements. Those create bubbles in your processor
pipeline which are going to kill your performance much
faster than initializing each pixel 3 times.
It's a good thing we are working with small images on fast
computers. :)
No reply requested.
------------------------------------------------------------------------
[2006-11-04 19:32:15] pajoye@php.net
A last comment is this free support session, you certainly do not know
that the default contents of an image create by imagecreatetruecolor is
black and not transparent/NULL.
------------------------------------------------------------------------
[2006-11-04 19:21:46] pajoye@php.net
"That is a workaround. imagecopyresized() isn't working as
defined in the manual, so you've changed the destination
image to compensate."
Now you've reached my patience limit.
http://blog.thepimp.net/misc/bug39353_with_alpha.png
is exactly what you expect.
Now if you do not understand the different between the TRANSPARENT
COLOR and the alpha channel of each independent pixel, I cannot help
you further.
But you keep considering other apps behaviors as what should happen in
gd. It is not the case for various reasons (backward compatibility is
one of them).
"But I've seen worse code in the GD library..."
For example?
------------------------------------------------------------------------
[2006-11-04 19:16:05] seth at pricepages dot org
That is a workaround. imagecopyresized() isn't working as
defined in the manual, so you've changed the destination
image to compensate.
I suppose it's fine if you don't want to fix it, I think I
can use this workaround for now.
There is a waste of pixel processing, though. You need to
process the entire final image twice. But I've seen worse
code in the GD library...
------------------------------------------------------------------------
[2006-11-04 18:59:26] pajoye@php.net
$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39353
--
Edit this bug report at http://bugs.php.net/?id=39353&edit=1