ID:               39353
 Updated by:       [EMAIL PROTECTED]
 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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

"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] [EMAIL PROTECTED]


$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

Reply via email to