Spatial's 3D InterOp requires that all translations be done on the same thread that creates the SPAISystemInitGuard. This complicates programs that may wish to create separate threads for a translation. This is often done in GUI applications that require the main thread to listen for events and handle all translation logic in a separate thread that will not impact the interactivity of the main thread. It would be highly undesirable to block all event processing for the duration of a translation, so a separate thread is often used to do the translation so that the application can still be interactive.
Spatial has recommended that you follow the guidelines established in the document “InterOp: Important Note for Multi-threaded Applications.” However, the example code there is specifically for file to file translations. The classes provided do not demonstrate how do to in-memory translations or provide a flexible mechanism for doing arbitrary translations on any arbitrary thread. It is far easier to spawn a new thread in an application for the translation and then close that thread when done. IOP does not support concurrent translations, so some caution must be made to not accidentally do two translations at once.
This of course gets more and more complicated for real world applications. Often, a single code path for a translation cannot be maintained. In one translation, you may want to only process BREP data. In another, you may want graphical data. In yet a third, you may be interested in a file-to-file translation and not care to process in memory. This requires different code paths per translation and it is no trivial task to modify the example code into something that works for type of translation you may have.
With the proper encapsulation, one class can manage all translations and drive them in such a way so that the conversion is done within the boundaries of one and only one SPISystemInitGuard. It will allow you to spawn and then destroy a thread in your application so that code management is easier and the translation is localized. It will allow you to implement any number of callbacks so that not only one translation code path is needed. It can handle multiple different translations in an application with the reassurance that it abides by the restrictions of InterOp translators and does not force any of event processing threads to synchronously block for the entire duration of a translation.
To view an example of flexible code for use by any program that may invoke arbitrary threads to do translations, visit: http://info.spatial.com/3dinterop_translationdriver
ACIS, 3DScript and SAT are registered trademarks of Spatial Corp.
No Comments Yet
Let us know what you think