Read of PDF suspends while showing "Loading..." rather than a page

[gnu]

Build 691, G1G1 MP laptop, Q2D13.

I went to:

http://www.archive.org/details/animalkindomarr03cuvi

and downloaded the PDF ebook (42 MB) from the left margin. While it was downloading, I switched to the Journal with Alt-Tab. Once the download was complete, I clicked in the circle in the right margin of the Journal, which started Read to read the PDF book.

Once Read came up, it displayed a page that said "Loading..." and then went into suspend. Hitting the space bar didn't improve this. After several other space bar presses, I figured out that it is incrementing the page number, not managing to update the screen, and forcing the machine into suspend. One page showed up (a blank but colored page).

It worked better to wiggle the cursor with the mouse pad to wake it up. Then at least the 15-second suspend timeout would often result in the rendering finishing before the suspend. :-)

I had a similar problem after hitting the rotate button and trying to use the cursor pad next to the screen to read the book. Hitting "Down" (toward the rotate button) would scroll me down slightly, but it would often bring up a "Loading..." page and then suspend.

It appears that there is just some obvious bug that makes it force a suspend when Read still has a lot of work to do to get the screen updated.

[bert]

Wonder if this is related to #6623 ...

[frankprindle]

This is still happening in joyride 1741, which is the latest image I can find to download today.

Basically read should render the current page and then render to its cache the next 2 pages. THEN if the user is still reading the first page, it's fine to suspend, but no sooner. As soon as he/she tries to advance to the next page, it should unsuspend and proceed to display that (cached) page and render the 4th page, THEN it can suspend again until the next user event. And so on. Also, read keeps the previous page in its cache, so going back a page will display the previous page immediately but should take a while to render the page previous to that to be cached before suspending.

For example, reading this book: http://www.archive.org/download/flatlandromanceo00abbouoft/flatlandromanceo00abbouoft_bw.pdf , each page takes perhaps 20-30 seconds to render, so it's very important that the next 2 pages be rendered in the background before suspend.

BTW, don't even try to read pages 4, 5, 6, or 7 of this book, as page 6 causes read to eat up all memory and crash hard (this is the subject of another ticket, #5869.) Fortunately, there's nothing terribly important on those pages.

[rwh]

Update.1 has suspending disabled, so this problem should not be an issue there.

Your comment about rendering ahead is kind of a problematic: at the moment I'm actually looking more at limiting the pre-rendering due to memory consumption (which is by far our biggest concern, and I think the problem with page 6 crashing). I'm also working with the evince developers to improve the rendering mechanism to support tile-based rendering.

[gnu]

I'm having trouble confirming your statement that "Update.1 has suspending disabled." I was running update.1 (build 691) at the time I reported this bug. But update.1 apparently means many things to many people. Please confirm:

Does the current version of Read entirely eliminate the forced suspend kludge that was unique to Read? I see no Trac ticket for doing this, and the source tree at http://dev.laptop.org/git?p=projects/read-activity;a=blob;f=readactivity.py;h=3992290d0a9194742c82d9a924e0c15bd32bfea3;hb=master still has plenty of suspend stuff in it. In particular, it calls self._service.set_kernel_suspend (whose definition appears to be in /usr/bin/olpc-hardware-manager!!! I can't figure out how that could be in scope to be called by Read!) which does a direct write to the kernel, rather than going through HAL or Ohm to decide any policy questions about suspending). So if this code is what's running, in what sense does "update.1 ha[ve] suspending disabled"?

Is that hypothetical Read change approved for inclusion in update.1?

Is it in the current release candidate? (What release candidate *is* that, so I can test it?)

Thanks...

[rwh]

Read calls set_kernel_suspend on the hardware manager service; it does not execute the suspend call itself (although I think this structure might change in the future). This communication path is enabled explicitly.

You can inhibit suspend by touching /etc/inhibit-ebook-sleep. This was created by default in in update.1-694, see #6569

[kentsin]

I have trouble getting pdfs which were big (with scanned pages) to display.

First I through it is a memory problem, I add a swap, but still the display is not shown. However, I look into the system with free it show that the system does not use swap space at all.

Free tells there are still planty of memory left for the system, but the pdf file never got loaded. The display is a blank grey, the page number is 0 / .

[gregorio]

Milestone Never Assigned deleted

[mstone-xmlrpc]

Pushing out to 9.1.0, per edmcnierney's request.