By Harry Fuecks

PHP extension for Cairo graphics library

By Harry Fuecks

Thanks to tip off from Jared “Ren” Williams (is that you? – any link?) here – the Cairo wrapper extension by Hartmut Holzgraefenice demo.

Cairo is the “next generation” vector graphics library for Linux and very cool to have it available in PHP. Also cool about the extension was created using PEAR::CodeGen_PECL, which Hartmut describes here: look Mum – no C! (well almost).

This raises the question of whether it’s time to depreciate GD? As far as I’m aware, it and the PCRE extension are the two main problem children preventing PHP from being thread safe. It may be possible to replace PCRE and preserve backwards compability, with ICU regexes, which claim to based on Perl’s regular expressions. Dropping GD would be much more painful but with Cairo and the imagick extension, there might be enough to keep everyone happy. This is in the interest of running PHP under Apache mpm. Would be interested to hear thoughts / opinions on how realistic that is?

Side note: my dumb view of the difference between GD and imagemagick is the former is more for image creation while the latter is more for manipulating existing images.

  • Ren

    Yes, its me :)

  • Ren

    I do think GD should be deprecated and put into pecl. The quality of some of its drawing primitives aren’t that good. And the amount of effort to get it up to scratch seems wasted when there are existing usable api’s out there.

    As for imagemagick, the magickwand api is definately suited to both creation and manipulation.

    Draw*() & Pixel*() functions for creation, and Magick*() for manipulation.

    Seems magickwand site seemingly has removed the gallery with one or two of my examples.

  • A little nitpick…

    “This is in the interest of running PHP under Apache MPM” is akin to saying “This is in the interest of running a script under PHP SAPI”, or “I opened it in Adobe.”

    MPM == Multi-Processing Module, and if you use Apache 2, you already use an MPM–if you use PHP on anything but Windows, hopefully you use the prefork MPM (forks one child per request, just like Apache 1). The Worker MPM (which is what you meant, of course) is thread-based, and improves performance for most applications.

    Also of interest (especially for virtual hosting) is the Perchild MPM, which also doesn’t work for the same (and different) reasons (-:


  • didimo

    one word


  • The Worker MPM (which is what you meant, of course) is thread-based, and improves performance for most applications.

    Thanks for picked nit ;) That’s what I meant.


    But that’s FastCGI

  • Pingback: Script Artists | Cairo PHP Wrapper()

  • Pingback: Full(o)bloG » Blog Archive » Cairo per PHP()

  • patrikG

    Had a discussion with a colleague because of your blog (which is a good thing) and tried to find a list of thread-safe (or ZTS: “Zend Thread Safe”) extensions. Couldn’t find anything, and thus not really establish whether pcre is thread-safe or not (apart from your comment at
    Care to shed some light on it?

  • streaky

    one word


    one word: mod_rewrite ;)

  • tried to find a list of thread-safe (or ZTS: “Zend Thread Safe”) extensions. Couldn’t find anything,

    Actually never seen anything like that either – I’ve seen PCRE and GD mentioned before (somewhere – perhaps PHP internals list – can’t remember) as being non-reentrant but perhaps I shouldn’t believe everything I read online.

    You got me wondering more though and perhaps this highlights the problem with even compiling a list in the first place;

    > Is there a short list of some common extensions that do work reliably
    > with Apache 2? (eg MySQL, GD etc…)

    Nope. Make one. It’s not all that easy to create such a list. Just take
    a single library and go through it and tell me if it is threadsafe. Can
    you do that? Do you know what to look for? If it is threadsafe on one
    platform, do you think it is threadsafe on another? Does it depend on
    which version of libc is on a platform? Does it depend on how it was

    There’s also this remark (Andi Gutmans);

    You will most likely find that the “faster” Apache way with
    thread-safe PHP is slower than the slower Apache way with
    non-thread-safe PHP. And even FastCGI will be faster :)

    That seems to tally with what Sara Golemon says What the heck is TSRMLS_CC anyway? (comments);

    > Is the overhead of lookups in tsrm_ls significant,
    > when in ZTS “mode”? Put another way, why not have everything thread safe
    > and discourage the use of globals completely?
    At the CPU instruction level, it’s the difference between:
    Fetch a local value


    Fetch a local value,
    dereference it,
    Fetch a local value,
    Seek forward from that first dereference by that second local value,
    Dereference that,
    seek into that pointer by X bytes and dereference that value

    Any guesses which is faster? Now multiply that difference by EVERY INSTANCE of xG() in the engine.

    That leads to some depressing conclusions.

  • Ren

    I can’t see that last sequence being more than a few cpu instructions. I’d like to see some profiling data between the two, to see how much time it apparently takes over non-thread safe.

    I’d bet other design decisions have a far greater impact on raw speed than the running with thread safety.

  • patrikG

    That leads to some depressing conclusions.

    Indeed, but Rasmus has spelled them out(12 Dec. 2005)

    Bart de Boer went ahead anyway and asked whether there are any future plans for native multithreading support in PHP?
    Rasmus denied it, saying that asynchronous mechanisms offer a more efficient approach. Bart clarified this – by ‘asynchronous mechanisms’, did Rasmus mean calling other scripts, such as web services, from within the main script? He’d regard that as a good alternative, apart from the extra overhead, scripts and code…

    It’s an answer just as cryptic as you’d expect from the Oracle at Delphi (not the IT-stuff, but Greek mythology). Why would and how could webservices make up for PHP extensions? GD-library via webservices? Did some more research and at some point my head started spinning with acronyms and comparing concepts I knew not too much about at all. Then decided to think “What an interesting discussion” and have a cup of tea.

  • Mark

    I have used both Imagemagick, and GD. I agree Imagemagick is powerful but it is also slow and resource hungry compared to the GD library. I think to deprecate GD would be a major step backwards for PHP. If thread safe is what you want need then disable GD on your own installation.

  • Pingback: All in a days work…()

Get the latest in Front-end, once a week, for free.