Quote:
|
Originally Posted by Henrycat
Correct me if i'm wrong, but are you saying caching the whole book to memory, so it would only flip to another page when i jumped?
I suppose with text books it could work... my pdfs have been between 2-4 megas.
But my Beserk mangas in PDF are 120 megas (size of my CF), so how would you do it for that?
When i jump from pages it doesn't seem to take that long compared to just fliping to next/previous...
|
Nope, that's not what I meant. From what I saw in the vids, I'd say the slow page flip is mainly caused by the actual rendering of the pdf - neither accessing the filesystem nor updating the eink screen. This "caching" other's are talking about would essentially mean that while you read page 5, a background process would render pages 4 and 6 in advance, and possibly remember rendered pages once you leave them. Of course, this doesn't improve anything if you jump from page 5 to 700, or if you spend no time on page 5.
So the idea is to render everything on your desktop pc and create one grayscale image per page. 1024x768 pixels with 16 colors is uncompressed(!) 384kbytes. So instead of storing a 15-page pdf on the iliad, I'd store a format that holds 15 images. That should reduce rendering time to nothing, with no visual difference (you can't zoom tho). Page flipping would just be reading the correct portion from the file and copying it directly into the framebuffer.
It doesn't help at all with your 10-billion-pages monster pdfs, and it will probably not work for novels, where every page is about ~1k text in a single font. The pdf's I have use lots of differents fonts on every page, have diagrams and such. Sometimes they take multiple seconds to render a page on my 2GHz processor - what will this be on a 400mhz cpu without fpu?