[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] DCT filter: suspending or buffering
From: |
jemarch |
Subject: |
Re: [pdf-devel] DCT filter: suspending or buffering |
Date: |
Mon, 15 Dec 2008 22:51:19 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
Hi Yang.
Normally, the data feeding to libjpeg decompressing is done in a
callback function (in which way I think pdf might take...). That means
there is no chance to return a ENINPUT to outer loop to get more input
data so we need a internal buffer to cache all compressed data and put
them into libjpeg.I don't know wether it's acceptable.I mean, if there
is very huge jpeg pic...
Or, there is a another mode of I/O of libjpeg, suspending in which the
decompressing will return if it needs more input.But the document says
there may be a performance issue in this mode.No promise of the running
time.
I'm proceeding along to the first choice.I think maybe we can adjust pdf
I/O interfaces or implement both of the modes of libjpeg without
changing our interface.
We definitely want to use the suspended mode, using jpeg_read_header,
jpeg_start_decompress, etc. We should avoid to store the entire
contents of a PDF stream in memory: these streams can become really
big!.
Don't worry about the performance issue.