I need help - I can help - RenderPageToString: How to free result memory

Print Page | Close Window

RenderPageToString: How to free result memory

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=2702
Printed Date: 19 May 24 at 11:30PM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: RenderPageToString: How to free result memory

Posted By: kmsb12
Subject: RenderPageToString: How to free result memory
Date Posted: 05 Aug 13 at 2:16PM

I am using the RenderPageToString and the DARenderPageToString functions of the Quickpdf library.

Those functions return me a pointer to char (char*) to the rendering results. The memory holding the result data will not be freed until I call RenderPageToString again. The memory will not be cleaned up when I call DACloseFile either.

I found out that I can call DARenderPageToString with an invalid pageRef (0 for instance). The memory from the last rendered page is cleaned up and no new memory will be reserved for the next page rendering.

My question now: Is there any official function for cleaning up memory and invalidating the render results or do I have to live with my workaround?

Thanks a lot.

Kristoff

Replies:

Posted By: Ingo
Date Posted: 05 Aug 13 at 6:33PM

Hi Kristoff!

I think you'll need the FREE ;-)

Another hint: Don't mix (never!) DA... and non-DA-functions!

Inside a try...create...finally...free...end you should use DA... or non-DA but never both!

This you can read in the online-references, too ;-)

Cheers and welcome here,

Ingo

Posted By: AndrewC
Date Posted: 06 Aug 13 at 4:33AM

Kristoff,

DQPL maintains a buffer to return data from the DLL. As you have correctly determined the memory is not freed again until the next call to the DLL. You could call something like QP.LibraryVersion which will return a much much smaller buffer effectively freeing the larger buffer from the previous DLL call.

Andrew.

Posted By: kmsb12
Date Posted: 20 Aug 13 at 4:25PM

Thanks for your answers!

QP.LibraryVersion did not work for me.

I now free the library with delete (I am using the C++ wrapper of the library)

Posted By: tfrost
Date Posted: 21 Aug 13 at 10:51AM

Are you absolutely certain that your main program and the DLL use a common allocator and common memory pools, and always will in future? Allocating and freeing memory on opposite sides of a DLL boundary is normally a recipe for subtle problems which hit you long after the event, when the pool is next used.

Posted By: kmsb12
Date Posted: 21 Aug 13 at 3:40PM

tfrost wrote:

Allocating and freeing memory on opposite sides of a DLL boundary is normally a recipe for subtle problems

To clearify, I do not delete the memory block holding the pixel data directly. I tried that too, but it did not work Wink

Instead I delete the whole library object.

DebenuPDFLibraryDLL0914 *pdfLib = new DebenuPDFLibraryDLL0914(...);

...

// do whatever with pdfLib

...

delete pdfLib;

By doing this, I have to recreate the library object again every time after destroying it. But that's OK. As I use the DA... (direct access) methods, I do not need to reload the whole PDF file as I instantiate the pdf library.