Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#9 Adding client_data to MonitorHandler callbacks


When working with more images simultaneously, It'd be useful if monitor handlers could get some data to identify for which image the handler is called. Passing client_data or the image pointer itself could be a solution.


  • I agree that the progress monitor design is lacking since it is not object-oriented. There is not necessarily an image pointer or client_data when the progress monitor is invoked so passing either of these won't work. However, the ExceptionInfo pointer is passed to the progress monitor. This could be an ExceptionInfo which was allocated explicitly by the caller (you), or the one embedded in an Image, depending on the API being called. In a few cases, an ExceptionInfo may be allocated on the stack internal to the library. If the caller always arranges to provide a unique ExceptionInfo (when ExceptionInfo is needed) then it it is at least possible to discriminate between progress monitor sources, even though it may not be clear which Image is being worked on. There may be cases where the progress monitor is invoked for a task which is not related to working on an image.

    ExceptionInfo is part of the ABI, and is often allocated on the stack, so it is not possible for me to add new members to it at the moment. You could commandeer some existing arguments for your own use, but they may be overwritten if an exception is thrown.

    In a build using OpenMP, the progress monitor is invoked by multiple worker threads so it is not possible to use the invoking thread ID to know which task is being worked on and the progress monitor callback needs to be reasonably thread safe. For a given task, the worker threads invoke the progress monitor serialized by a task-specific critical section, but for concurrent tasks, the progress monitor could be invoked by multiple threads at once.

    Updating the progress monitor is a huge amount of work since it is invoked in thousands of places in the code. I was quite bleary-eyed after updating the code to use MagickMonitorFormatted() rather than MagickMonitor(). After the update to use MagickMonitorFormatted() I tried to make sure that there is a useful identifier for the filename in the progress monitor string. This always occurs between brackets. For example:

    % gm convert -monitor seaworld.ppm -sharpen 0x0.5 crap.ppm
    100% [seaworld.ppm] Loading image: 1530x1020...
    100% [seaworld.ppm] Convolve: order 5...
    100% [crap.ppm] Saving image: 1530x1020...


  • igy137

    I completely agree, this is a huge manual piece of work, I've added client_info to this callback as a temporary fix to two versions, that's exactly why I thought I could probably spare some time later by asking for this feature :-)

    Regarding image/client_data availability, there're around 370 places this is called, and I found one single place (in ReduceImageColors) where there's no image pointer available.

    I'll take a look into ExceptionInfo, although getting client_data makes it very easy to add some internal data storage without the need for parsing text/looking up objects.

    • labels: --> C API features