Re: Imlib support...

On Wed, 18 Oct 2000, Marko Karppinen wrote: > > Well, the neat thing about Imlib2 is it is extensible... I.e. it has a > > plugin style architecture, and since it's also being driven by > > Enlightenment and sorta therefore by Gnome, it really is shaping up very > > nicely. Doing home grown stuff is nice, but unless you have some really > I've exchanged a few thoughts with Matt McClanahan, the author of the > php_imlib module, about his work and Imlib2 in general. To me, the problem > is the unix-centric nature of Imlib2 -- after all, it does require the X > libraries among other things. X is less of a problem now, but there are certainly other aspects of Imlib2 which make it rather Unix-centric, yes. One issue of particular concern which could make Imlib2 a poor long-term choice for PHP is the fact that its API is severely non-thread-safe. I had an interesting conversation with Raster on this subject, and the man quite stubbornly :) holds to his position that API backwards-compatibility is more important than thread-safety. He's willing to implement pthreads support within the library itself, but won't change the API to make the library portably thread-safe. So it will never be a very good choice for use with ISAPI or NSAPI, and I imagine even getting it to work well with Apache 2.0 could prove painful. > The imaging backend PHP needs is really, really simple. We're probably > talking about a smaller code base than the current GD distribution, and > that's pretty small. We need to be able to work with 32-bit ARGB images and > do basic cropping, scaling and blending operations; add FreeType 2 support > and file-format plugins as garnish and you're pretty much done. > Of course it's not as simple as that. But it's not that complicated either, > especially since the world is full of the needed routines for manipulating > raw 32bit images. I find Imlib2's speed and excellent RGBA support quite impressive, and I think that for the time being this library makes a nice addition to PHP. But if someone would be willing to take on the duties of maintaining an equivalent thread-safe library, that would almost certainly be more useful to the PHP community in the long term -- and there's no doubt it would be easier than convincing Raster to change his API. ;) Steve Langasek postmodern programmer