pdf must be rendered in a multi-threaded way

[GoogleCodeExporter]

Purpose of code changes on this branch:
Make faster pdf-to-image rendering using cash logic.

Explanation:
Now, it takes time to change slide numbers as pdf-to-image rendering is done 
depeding the click on right/left arrows. So, it will be changed by using cash 
logic; keeping some pdf pages rendered in the cash in a multi-thread way.

Original issue reported on code.google.com by utkusi...@gmail.com on 16 Mar 2011 at 8:18

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

First version is on r57. an array size of 3 keeps left and right of the current 
page. It is loaded in a seperate thread (related source file is 
renderedimagecash.cpp). If user stands at least 1 second on the page, it is 
loaded fast as only 3 item is kept - that is why only 3 item. cash is renewed 
after each change on the currentSlide number.

Error :

If any page is annotated and actionNext() is performed, it immediately exits 
from the program. However, this error appears in r56, also. So i think it is 
not related the cashing algorithm.

Improvement - or the other way:

keep 5 items in memeory - +- 3. if required slide in the cash, just bring them. 
If it is not just bring it in a usual ways, renew the cash.

This will be handled in r58.

Original comment by utkusi...@gmail.com on 16 Mar 2011 at 6:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Note that: 

the resolution on the function renderToImage(,) is taken as 120. It may be 
changed accordingly.

Original comment by utkusi...@gmail.com on 16 Mar 2011 at 8:12

[GoogleCodeExporter]

r58. The change in the previous comment has been applied. Now, only after four 
page the cash is renewed. There is an array of size 7. Example:

At the beginning,

-2. -1. 0. 1. 2. 3. 4. slides are in the array, only slide numbers that are 
bigger than 0 are loaded. When user attempt to go to 5. page, cash is renewed 
and:

2. 3. 4. 5. 6. 7. 8. slides are loaded to the cash. This goes like that.

Error:

The error in the previous comment seems still to exist. :(

Discussion:

For machines with small ram size, it may be required to save images as files 
and load them when it is required, instead to keep some of them in the memory. 
Pros and Cons will be discussed.

Moreover, saving all rendered images as files and still keeping some of them in 
the memory by loading them from file may be faster the system. This will be 
tried in r60.

Original comment by utkusi...@gmail.com on 16 Mar 2011 at 10:38

[GoogleCodeExporter]

note that r59 is the fixed form of r58. There was a minor bug. Different 
presenatations cannot be opened in r58(in r57, also) it is fixed in r59. 

Original comment by utkusi...@gmail.com on 16 Mar 2011 at 10:40

[GoogleCodeExporter]

r60 is ready. One more point to discuss may be make the system in r57 just as 
in r60. That is, render all images and save them in a directory. When it is 
required to load them to the ram, load them from files directly, not render 
them. 

File Loading -- Rendering Time, trade off.

As any renewal causes a conflict in r57, it will be integrated after the 
decision of the method that will be used. Code is almost ready, just 
integration will be done.

Original comment by utkusi...@gmail.com on 17 Mar 2011 at 8:39

[GoogleCodeExporter]

Original comment by malta...@gmail.com on 23 Mar 2011 at 3:48

• Changed state: Fixed