I have been requested to solve a problem of memory usage of a CAD application written on Visual C++ that occurs when trying to export the drawing to PDF3D.
Exporting feature behaves well for simple models or only parts of a complex model, but not for an whole complex model.
We are using the U3D sourceforge project for creating the U3D object; after we insert it into the PDF. It is the object creating part that is problematic.
The U3D sourceforge project is a library built in C++ for use in C++ too that is dead since 2007, has a poor documentation and its samples’ collection is far from enough! In the TODO list of the project is also stated that it has memory issues!
So I have been asked to attack the problem by two sides:
-
Do maintenance of the U3D code.
-
Change the way the application interacts with the U3D library.
They also said the side 2. preferrable, as it is under our control.
When trying to solve the problem, I got two conclusions:
-
I am strongly suspecting that the U3D method EncodeX is responsible for memory misusage.
-
I tried a lot of changes of small things for the way the apllication interacts with the lib (changing compression parameters, flags, etc) and everytime the result was memory over-allocation.
So the question is: Is it worth to continue using this library? The code of it is not a joy to read… Or maybe it could be a good idea to look at other libs for the same purpose?
I didn’t explore them, but I am seriously thinking about switching to VCGlib or libharu… please suggest something else if you know that is good.
The other alternatives would be: use the Visual Technologies PDF3D exporter, which has an inacceptable cost, or to develop my own implementation of an U3D exporter,which would have the disadvanges of being a very limited set of the U3D funcionality and also it could’nt get ready for the expected deadline.
So take these options as forbidden.
I really need help to decide what’s best.
Thanks in advance,
Sérgio
After some desperation and bad-sleeping nights, trying to discovery memory leaks or some other memory troubles, we concluded for the most practical solution:
Extract only the code part needed to load a file and export it as U3D to a small program and make the main CAD application call it. Even though it is not the most elegant solution, it really works well – none of the processes reaches memory usage even close to the 2 GB barrier.
I wish I had been authorized to solve things this way earlier. I proposed some other things like:
migrating to 64 bits
use an option that modern Windows versions support for extending the memory limit of each process to more than 2 GB
None of these two solutions were acceptable, because it would be needed to force some customers to reinstall already-running hardware or software.