[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Changes in GraphicsMagick-1.3.8
From: |
John W. Eaton |
Subject: |
Changes in GraphicsMagick-1.3.8 |
Date: |
Thu, 28 Jan 2010 01:46:41 -0500 |
On 27-Jan-2010, Marco Atzeri wrote:
| Hi,
| testing GM 1.3.8 versus previous 1.3.7 with octave 3.2.4,
| I discovered that from this version:
|
| "The InitializeMagick() function MUST be invoked before constructing any
Magick++ objects".
|
| http://www.graphicsmagick.org/Magick++/index.html
| http://www.graphicsmagick.org/api/api.html
|
| Otherwise a nice crash will happen.
|
| As I see no InitializeMagick call also in the hg source,
| Where is the best place to put this call within __magick_read__.cc ?
Looking here:
http://www.graphicsmagick.org/api/magick.html#initializemagick
I see the following description of InitializeMagick:
InitializeMagick
Synopsis
InitializeMagick( const char *path );
Description
InitializeMagick() initializes the GraphicsMagick
environment. InitializeMagick() MUST be invoked by the using program
before making use of GraphicsMagick functions or else the library
will be unusable.
This function should be invoked in the primary (original) thread of
the application's process, and before starting any OpenMP threads,
as part of program initialization.
The format of the InitializeMagick function is:
InitializeMagick( const char *path );
A description of each parameter follows:
path:
The execution path of the current GraphicsMagick client.
So this seems to say that we have to call this in the main Octave
program instead of from the .oct file? So writing your own plug-in
using GraphicsMagick is not guaranteed to work unless you also have a
way to have the main program call some initialization function for
you? And you need to pass that function the full filename of the
program? Ugh. What is InitializeMagick doing that it needs this
special treatment? OK, I looked. It is doing a lot of stuff,
most of which we probably don't need if all we are doing with the
library is reading and writing files.
There is also DestroyMagick, which is supposed to be called when
shutting down, but the docs for that don't say that it is necessary.
Oh, I see now that GraphicsMagick apparently handles this with a call
to atexit.
OK, if this really is required to be done at program startup time,
then I guess we might as well make __magick_read__.cc part of
liboctinterp instead of linking it dynamically.
jwe