PHP extension for Cairo graphics library

By | September 5, 2006 | PHP

14
  • Print
  • Print

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.

Written By:

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.

 

{ 11 comments }

Mark December 10, 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.

patrikG September 9, 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.

Ren September 9, 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.

HarryF September 9, 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.

streaky September 8, 2006 at 6:51 pm

one word

lighttpd

one word: mod_rewrite ;)

patrikG September 7, 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?

HarryF September 6, 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

didimo September 6, 2006 at 3:34 am

one word

lighttpd

scoates September 6, 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

Ren September 6, 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.

Ren September 5, 2006 at 11:38 pm

Yes, its me :)

Comments on this entry are closed.

{ 3 trackbacks }