octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]