grey typewriter style like this.For each section, important details are shown in bold for recognition.
For NT, visual C++ is required, or any compiler that will generate .dll files. The NT nmake will work on the supplied makefiles.
Exactly how this information is stored is described in chapter 5.
When the user chooses a node and places it onto the Chalice workspace, two copies of the node are created: one runs in the UI process, taking values from the user via the user interface tabs that all nodes have, and the other runs in the work process, which does the actual image processing (recall that Chalice is actually always running two processes, a front process to interact with the user and a back one to do the work).
Thus for each instance of the node on the workspace, there will be an instance running the user interface process. But there is only one copy of the node in the work process area. This copy will be executed at each invocation of the node.
Warning:
Chalice does not police the user's use of memory, pointers or other resources
in plugins. It is very possible to write plugins that run amok in
memory or on disk. It is the plugin writer's responsibility to
write well-behaved code.
The following functions are called once, when Chalice starts
up (actually, they are called twice, once by Chalice, once by the
work process). They are called in the order given, and then never
called again:
upiInitialize
upiPluginType
upiAuthorName
upiPluginName
upiCopyrightNotice
upiPluginVersion
upiCreateParameters
upiNumberOfInputs
Then, the following sequence of upi functions get called during
the cooking process:
upiOutputContext
upiCheckInputSize
upiCheckInputDepth
upiRegionsNeeded
upiCookFull
upiResultInput
upiRegionsNeeded
upiProcessImage
They get called in that order (though upiOutputContext can get
called a few more times). Also note that upiRegionsNeeded is
called twice. The first time is used to figure out the caching
situation (i.e. figure out how many times an image is used, etc...).
The second time it is used to actually do the cook.
It is also worth saying that upiOutputContext is called many times within
the execution of a single plugin, so it should be efficient.
These functions get called whenever something changes:
upiInputChanged
upiParameterChanged
upiNodeCreated
upiNodeDeleted
upiNameChanged
These get called when the user wants some information:
upiMessageInfo
upiInputLabel
upiOutputLabel