Menu
▾
▴
#12 WebMagick should support GraphicsMagick
WebMagick should support GraphicsMagick in addition to ImageMagick. The main difference to support GraphicsMagick is that all mentions in the webmagick script like "Image::Magick" needs to be substituted to "Graphics::Magick". Otherwise the PerlMagick APIs are similar. This substitution could be done via the configure script using sed after autoconf has performed its own substitutions.
I have attached a webmagick script which has been hacked to work with GraphicsMagick. I don't recall what other changes I made have made to the script.
A webmagick script which runs with GraphicsMagick
Please enlighten me why Graphics::Magick will be better for our case. ImageMagick is actively developed, so I don't see any obvious advantages (at least for functions we use).
GraphicsMagick is usually more CPU-efficient than ImageMagick. While it is true that WebMagick is likely bottlenecked by the JPEG library and filesystem I/O operations, it seems useful to provide the WebMagick user with the alternative of using GraphicsMagick.
Being the principle maintainer of GraphicsMagick, and being the original developer of WebMagick, it caught my interest yesterday that it seems that WebMagick is suddenly being maintained again so perhaps there is hope of GraphicsMagick being directly supported by WebMagick without special hacks.
In that case it should be configure task to satisfy both kind of users, autosensing which *Magick is installed, asking when both are installed. With configure option to override autosensing. Could you please provide configure.in and webmagick.in pattern substitute patch for it? (I don't have GraphicsMagick at this moment to test it properly.) And IMHO webmagick does't need to issue 'use Image/Graphics::Magick' statement several times, one time at the start of the file will be enough.