search

JohnsonGao / pdfium

Automatically exported from code.google.com/p/pdfium
0 stars 0 forks source link

Memory intensive JPEG2000 loading / rendering #163

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

Monitor memory usage while rendering the only page of the attached PDF.

/usr/bin/time -f "%M KB" out/Debug/pdfium_test "~/Downloads/Ruimte B8 magazijn 
ETOS 3-4-2015.pdf"

What is the expected output? What do you see instead?
Expected:
PDF file is 200KB, the uncompressed bitmap from the embedded JPG image should 
be about 33MB - would hope to render in less than 100MB.

Instead:
I see around 350 MB used, which seems to be leading to slowness on mobile 
devices.

What version of the product are you using? On what operating system?
chromium/2391 on linux and on android.

Please provide any additional information below.

Original issue reported on code.google.com by ol...@google.com on 27 May 2015 at 7:40

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by jun_f...@foxitsoftware.com on 27 May 2015 at 5:19

GoogleCodeExporter commented 9 years ago 
Memory usage is usually a complicated issue. It's not easy for us to estimate 
reasonable memory usage for pdf rendering. The memory usage depends on the 
content of pdf files. In this case, it takes most memory in the following main 
process: parsing PDF file, decoding JPX and rendering decoded bitmap. For 
example, the decoded bitmap is 33 MB. In order to decode JPX, some memory is 
used for buffer and data structures. The total memory usage can be twice or 
three times more than 33 MB in the process of decoding JPX. At the same time, 
the parsed result is still there and it keeps the memory. After JPX is decoded, 
twice or more memory is used for rendering.

Original comment by jun_f...@foxitsoftware.com on 27 May 2015 at 9:24

GoogleCodeExporter commented 9 years ago 
Seems to be a problem in openjpeg - either openjpeg is an inefficient library 
or .jp2 is a memory hungry format... either way, it may be difficult or 
impossible to find a fix.

Pfdium uses 350MB to render this file, but most of this is presumably openjpeg 
since using openjpeg's opj_decode directly using 260MB:

/usr/bin/time -f "%M KB" openjpeg/opj_decompress -i ~/Downloads/ruimte.jp2 -o 
ruimte.bmp

If I convert the embedded file to a 100% quality jpg, which is 3.2MB when 
compressed, and then embed that in a PDF, and render that using foxit, it only 
uses 95MB. So .jpg files are much less memory hungry.

If I re-encode the embedded .jp2 file with 512px square tiles, instead of a 
single tile as it has now, then openjpeg only uses 100MB to decompress it 
instead of the 260MB it uses now.

Original comment by ol...@google.com on 28 May 2015 at 2:00

Attachments: