Blog Post RSS ?

Blogs » PHP » PHP extension for Cairo graphics library
« Sep 4, 2006 News Wire
Sep 5, 2006 News Wire »
 

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 Holzgraefe - nice 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.

This entry was posted on Tuesday, September 5th, 2006 at 8:45 pm, contains 193 words, and is filed under PHP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. The views and opinions in this blog post are those of its author.

This post has 14 responses so far

  1. Ren Says:
    September 5th, 2006 at 11:38 pm

    Yes, its me :)

     
  2. Ren Says:
    September 6th, 2006 at 12:04 am

    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.

    http://www.magickwand.org/download/php/windows/manual/MagickWandForPHPManual.chm

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

     
  3. scoates Says:
    September 6th, 2006 at 12:26 am

    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 (-:

    S

     
  4. didimo Says:
    September 6th, 2006 at 3:34 am

    one word

    lighttpd

     
  5. HarryF Says:
    September 6th, 2006 at 8:33 am

    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.

    lighttpd

    But that’s FastCGI

     
  6. Script Artists | Cairo PHP Wrapper Says:
    September 6th, 2006 at 5:05 pm

    […] Via Sitepoint « Noch mehr Cheat Sheets […]

     
  7. Full(o)bloG » Blog Archive » Cairo per PHP Says:
    September 6th, 2006 at 5:41 pm

    […] Gli amanti di Gnome conosceranno sicuramente Cairo, la libreria per la gestione/creazione di oggetti grafici vettoriali facente parte del progetto FreeDesktop. Oggi ho scoperto grazie a Harry Fuecks che č stato fatto un wrapper per la suddetta libreria per interfacciarsi con php. […]

     
  8. patrikG Says:
    September 7th, 2006 at 4:26 pm

    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 http://programming.reddit.com/info/fhu0/comments).
    Care to shed some light on it?

     
  9. streaky Says:
    September 8th, 2006 at 6:51 pm

    one word

    lighttpd

    one word: mod_rewrite ;)

     
  10. HarryF Says:
    September 9th, 2006 at 7:28 am

    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
    compiled?

    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

    and

    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.

     
  11. Ren Says:
    September 9th, 2006 at 8:55 pm

    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.

     
  12. patrikG Says:
    September 9th, 2006 at 9:02 pm

    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.

     
  13. Mark Says:
    December 10th, 2006 at 11:20 am

    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.

     
  14. All in a days work… Says:
    December 14th, 2006 at 11:30 am

    […] PHP extension for Cairo graphics library 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. (tags: PHP Cairo) […]

     

Sponsored Links

Leave a response

You are not logged in, log in with your SitePoint Forum username and password.

-OR- Post Anonymously

* Make sure any code samples are escaped (i.e. ‘<b>’ becomes ‘&lt;b&gt;’).

If not logged in, your comments will be placed in a moderation queue. This means your comment may not appear until one of our moderators approves it.

Your Blogmaster is...

Harry Fuecks

Harry Fuecks

Harry has been working in corporate IT since 1994, with everything from start-ups to Fortune 100 companies. Outside of office hours he runs phpPatterns: a site dedicated to software design with PHP that aims to raise standards of PHP development. He also maintains Dynamically Typed: SitePoint's PHP blog.

Subscribe

SitePoint Newsletters

Get all the latest tips by signing up to all of SitePoint’s informative newsletters.

HTML   Plain

SitePoint Blogs

SitePoint Marketplace

Buy, Sell, Trade

Buy and sell Websites, templates, domain names, hosting, graphics and more.

Posting Code Snippets

Feel free to enter code snippets into your comments in the following format.

Marking Up Your Code
<pre>
<code class='html'> 
code snippet 
</code>
</pre>

Be sure to escape any HTML snippets (i.e. '<' becomes '&lt;' ).

Supported language classes include:

  • XML, HTML, XSLT and any other XML style code
  • CSS
  • C#
  • VB & VB.NET
  • Delphi, Pascal
  • JavaScript
  • PHP
  • Python
  • SQL