Memory leak with lots of images

[VilleImmonen]

Hi!

We are creating a Phonegap app that uses jsPDF to create PDFs on the fly on users phone. We are having a problem with jsPDF documents with images. On our android app one function is creating a PDF file with lots of JPEG images, with the size of the PDF file rising to over 5 MB. It seems that there is a memory leak somewhere and if we create a few large PDF files in a row, the app crashes because it runs out of memory. I have analyzed the memory consumption with GapDebug and the problem persist even when we remove all possible references from the code after the PDF is done. The only possible solution that we could come up with that would clear the memory was to entirely restart the app...

There are maybe 10 images in our pdf. We are using Chart.js and Konva.js to create images, convert them to base64 and add to PDF, like this:

var pie = new Chart(pie_ctx).Pie(pieData, {
          animation: false,
          segmentStrokeColor : "#D6D6D6"
});

var image = pie.toBase64Image();

doc.addImage(image, 'JPEG', 310, 105, 100, 100);

[Uzlopak]

Well, I think your problem are the generated images before they get added to the pdf. I guess they are saved as bitmap-files and not e.g. as jpeg with 60% compression. So changing the scaleFactor from the canvas could reduce the size of the image itself.

http://stackoverflow.com/questions/14488849/higher-dpi-graphics-with-html5-canvas

[VilleImmonen]

The problem is that we can create as many of these images as we want in a row, and the garbage collection clears them from the memory. But when we add it to pdf, suddenly the memory usage is remains super high even after the pdf and the image has been saved and otherwise discarded.

[MrRio]

There's a new method of adding SVGs to PDFs which may help you out on the 'feature/svg-html' branch.

Docs: https://rawgit.com/MrRio/jsPDF/feature/svg-html/docs/global.html#svg
Example: https://rawgit.com/MrRio/jsPDF/feature/svg-html/examples/canvg_context2d/svg.html

[MrRio]

Or there's actually a way to create a canvas for Chart.js to draw to (Commented out) that will convert the drawing actions into vector, using magic.

https://github.com/MrRio/jsPDF/blob/feature/svg-html/examples/canvg_context2d/bar_graph_with_text_and_lines.html#L680

[Uzlopak]

I think the problem is the addImage-Plugin.
https://github.com/MrRio/jsPDF/blob/master/plugins/addimage.js

Every Image is saved as base64-Text into an Object (line 134). So instead of loading and processing and then kicking it out of the memory, it keeps the images in the memory. There is not even a delete action after it is put into the pdf (line 108), because you dont know if it is used again in another place in the pdf.

[VilleImmonen]

I think the problem is the addImage-Plugin.

We tried drawing the pictures directly to the pdf with the method found in this comment:

Or there's actually a way to create a canvas for Chart.js to draw to (Commented out) that will convert the drawing actions into vector, using magic.

Like this:

    var image = pie.toBase64Image();

    var c = doc.canvas;
    var ctx = c.getContext('2d');
    ctx.drawImage(image, 300, 105, 100, 100);

And the issue still remains, without the addImage plugin.

It is hard to say if this is a problem in jsPDF or in PhoneGap/Android memory management. We are still trying to investigate this issue further. I will report any new findings..

[Uzlopak]

What happens if you change it to

    var images = {};
    images.image = pie.toBase64Image();
    var c = doc.canvas;
    var ctx = c.getContext('2d');
    ctx.drawImage(images.image, 300, 105, 100, 100);
    delete images.image;

or

image = pie.toBase64Image();
var c = doc.canvas;
var ctx = c.getContext('2d');
ctx.drawImage(image, 300, 105, 100, 100);
delete image;

?

[VilleImmonen]

This does not help..

[orodriguez2]

Hi,

I'm running into a similar issue as VilleImmonen, was this resolved at some point? If my only option is to use the SVG files I will have to convert 100's of them to be able to use them into my application.

Thanks,

[pablomaurer]

nope, never resolved..

[Uzlopak]

Try following:
find the line
jsPDFAPI.arrayBufferToBinaryString = function (buffer) {

comment out the first solution and activate the second method

return atob(this.arrayBufferToBase64(buffer));

Please give feedback about the result.

[orodriguez2]

@arasabbasi,

It turns out that the problem was indeed in my code. I was not using properly the new class instance. jsPDF works as expected. Thanks for your help.

[Uzlopak]

@orodriuez2
Just to document here your original comment before you edited it:

Changing to the second method does indeed maintain the memory low (~47K using Google chrome Task Manager, with the other one went to 1.6G). And the application doesn't crash the browser anymore.

Well I guess, there is a reason, why atob or arrayBufferToBase64 is not used. Probably because atob is not supported till IE 10. So keep this in mind, that you should test it properly.

[Uzlopak]

Can somebody test if this solves the memory leak problem? I dont know how to reproduce the memory leak.

@orodriuez2
@mnewmedia
@VilleImmonen

	jsPDFAPI.arrayBufferToBinaryString = function (buffer) {
			var data = (this.isArrayBuffer(buffer)) ? buffer : new Uint8Array(buffer);
			var chunkSizeForSlice = 0x10000;
			var binary_string = '';
			var slicesCount = Math.round(data.byteLength / chunkSizeForSlice);
			for (var i = 0; i < slicesCount; i++) {
				binary_string += String.fromCharCode.apply(null, data.slice(i*chunkSizeForSlice, i*chunkSizeForSlice+chunkSizeForSlice));
			}
			return binary_string;
	};

If so, then I would recommend following change for max compatibility:

jsPDFAPI.arrayBufferToBinaryString = function (buffer) {
		if (typeof(window.atob) === "function") {
			return atob(this.arrayBufferToBase64(buffer));
		} else {
			var data = (this.isArrayBuffer(buffer)) ? buffer : new Uint8Array(buffer);
			var chunkSizeForSlice = 0x10000;
			var binary_string = '';
			var slicesCount = Math.round(data.byteLength / chunkSizeForSlice);
			for (var i = 0; i < slicesCount; i++) {
				binary_string += String.fromCharCode.apply(null, data.slice(i*chunkSizeForSlice, i*chunkSizeForSlice+chunkSizeForSlice));
			}
			return binary_string;
		}
	};

[Uzlopak]

It is maybe better to set chunkSizeForSlice = 0x5000

[Uzlopak]

#425

[orodriguez2]

@arasabbasi,

I've tested the code above and it does indeed handle the memory much better. Now every time I create a pdf document with images the memory clears up and gets back to about 50MB, when with the prior code it was getting about 1300GB. The attached images show this using Chrome's task manager. The one in blue is the memory after generating a pdf. The one in yellow is after generating the same pdf with the new code.

Great work! thanks a lot for this.

[Uzlopak]

The problem was that the previous code is made for maximum compatibility on all browsers because the atob Function is not implemented in all browsers. If you use the generic atob function then the browserengine loads the whole base64 string into the memory and changes it to binary code.
The alternative algorhythm loads the base64-string char by char and not all in once. Thats why you have a memory leak.... The browser allocates for every char a byte. Few and Small images are no problem, but if you load hundreds of big images the browser engine needs alot of memory and the garbage collector doesnt realize that it can dealloc the memory.
Thats why i call the apply with the null parameter so it doesnt floods the window object with garbage. And second it will load the base64 string in much bigger chunks, so it needs less iterations to read the base64 string.
Thats why in chrome with using the generic atob-function it will now work much smoother.

It can still be a problem in IE9 or less. I had before a bigger chunk size and in chrome it didnt work properly. Thats why i recommended a smaller chunk size.

But if you just use chrome it should be from now on no problem.

[MrRio]

This is fixed in #1115

[sohilfynd]

@arasabbasi I am trying to generate pdf using html2Canvas and jspdf but after like generating 150 pdf pages, chrome memory utilization is too much. Can you tell what can be the issue?

[Uzlopak]

Sohilfynd, well what do you expect with 150 a4 Size images?

Please don't hijack issues. issue locked.