Speaking of GD, there is a very troubling problem that I have never found a straight answer to. The imagettfbbox function uses the baseline of the font for it's bounding box. What good is a bounding box without the decenders? Now if this were a simple calculation it wouldn't be so bad, but that doesn't seem to be the case. I have yet to be able to (or find an example of) calculating an accurate bounding box for any given text/font/angle/pointsize right down to the pixel on every side. Some come close, but that's not acceptible to a web page designer ;-) Is this a problem with GD itself, or something with the font files, or PHP's imagettfbox functionality? Is this something that could be "fixed"?
TIA Monte Sterling Hughes wrote: > Dmitry, > > Sorry, for the length of my reply, and now the fact that I'm just > refferring you to another source. I'm actually not responsible for the > gd library (at least since I last checked :). Your help would > definitely be appreciated, I've forwarded this request to > [EMAIL PROTECTED] which is the developers mailing list. If you > would like to work on the gd extension, please feel free to apply for a > cvs account at: http://www.php.net/cvs-php.php > > Thanks, > Sterling > > >>Hello, >> >>I have recently learned that GD library is being integrated into >>PHP, and apparently you have some relation to that. >> >>While GD library has a very good set of functions, the >>implementation is very poor in my opinion. The code is quite >>redundant and un-optimized in any way. This probably has to be >>addressed to the author of GD, but since it is now going to be >>part of PHP, may be some apparent optimization can be applied to >>the bundled version. >> >>My concerns raised when I tried to use ImageCopyResampled >>function. It nearly brings my server to its knees due to high >>memory and processor usage (when running 15-20 Apache processes >>each processing some image via ImageCopyResampled in PHP). The >>processing time is also very high - typically around 10 seconds >>for 1 calls to ImageCopyResampled with 1-2 megapixel images. >> >>Of course, those numbers relate to my server, people with faster >>computers may get better results. >> >>By in any case, I decided to look into implementation of >>gdImageCopyResampled in GD library and saw lots of this that can >>be improved. I did not look into other function, but I suspect >>this is true for the whole GD library. >> >>The function uses brute force approach and many values that can >>be calculated in the outer loop or outside of any loops are >>being calculated in the inner loop. E.g. >> >>sy1 = ((float) y - (float) dstY) * (float) srcH / (float) dstH; >>sy2 = ((float) (y + 1) - (float) dstY) * (float) srcH / (float) dstH; >>is being calculated for each x, while it really needs to be calculated for each y. >> >>This part is a constant: >> >>(float) dstY * (float) srcH / (float) dstH >> >>and therefore can be calculated once per call, not dstW*dstH*2 times. >> >>Similarly, >> >> int pd = gdImageGetPixel (dst, x, y); >> >>is being called inside of the inner loop (dstW*dstH times!) = but >>is not being used anywhere later! >> >>Applying some apparent mathematics, we can calculate the final >>spixels value in one easy step, rather than using (potentially) >>multiple floating point additions and multiplications in the inner loop (spixels >>+= xportion * yportion). Instead total spixels value for the current (x,y) can be >found as >> >>spixels = (y2-y1)* (x2-x1); // and, again, this can also be optimized further >> >>I can point out several other things that can be easily improved, but you got my >point already. >> >>It is possible to reduce number of calculation dramatically, without breaking >readability and/or >>compatibility. >> >>I am wondering if anyone is considering to do this any time soon. I would be more >than willing >>to discuss my suggestions with someone responsible for this library, or even modify >the code >>myself (a little bit harder for me, since I have little time to make extensive >tests). >> >>Regards, >>Dmitry >> >>-- >>Dmitry Petrov >>phone: (212) 641-3235 >>pager: [EMAIL PROTECTED] >> >> >>-- >> >>*** DISCLAIMER *** >> >>This message is intended only for the use of the individual >>or entity to which it is addressed and may contain information >>that is privileged, confidential and exempt from disclosure >>under applicable law. If the reader of this message is not >>the intended recipient or the employee or agent responsible >>for delivering the message to the intended recipient, you are >>hereby notified that any dissemination, distribution or copying >>of this communication is strictly prohibited. If you have received >>this message in error, please notify the sender by reply >>transmission and delete the message. >>------------------ >> >> > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
