DR1000 About PRE-FETCHING on PDF files

[bokjeid]

Hello everybody,
Through trying and testing many times, I found it out today that DR1000S pre-fetchs only the next '1 page'. So DR1000S suspends very frequently when turning to the next page on PDF files.

Can't we have DR1000S pre-fetch numerous pages, not only 1 page? Certainly it will help reduce the frequency of appearance of the loading dialog box, the most bothering one of the e-reader.

ps1. Can't we 'overclock' the CPU of DR1000S to make the loading speed of PDF files faster? I just wonder it.

ps2. I assume that my suggestions would help other DR1000S users and help activate this forum a little bit more..

[Mackx]

Hi bokjeid,

I appreciate you ideas to improve the DR. This idea however will be difficult to implement there are several reasons:
- The viewer framework of the DR (uds) is closed source, so its behaviour can not be changed.
- As indicated in another thread, there is a problem in the Adobe-plugin for the viewer framework w.r.t. postponing idle-mode when pre-rendering.
- Further the DR has only a limited amount of memory, so pre-rendering a complete document is not possible. Currently uds has a 'clever' caching mechanism, it seems to keep some of the previously viewed pages in cache, but only a limited number.

An alternative would be to develop a new pdf-viewer, so the behaviour can be specifically programmed for the DR. There have been some initiatives in the past on this forum, see for example this thread for pViewer.

[bokjeid]

Originally Posted by Mackx

Hi bokjeid,

I appreciate you ideas to improve the DR. This idea however will be difficult to implement there are several reasons:
- The viewer framework of the DR (uds) is closed source, so its behaviour can not be changed.
- As indicated in another thread, there is a problem in the Adobe-plugin for the viewer framework w.r.t. postponing idle-mode when pre-rendering.
- Further the DR has only a limited amount of memory, so pre-rendering a complete document is not possible. Currently uds has a 'clever' caching mechanism, it seems to keep some of the previously viewed pages in cache, but only a limited number.

An alternative would be to develop a new pdf-viewer, so the behaviour can be specifically programmed for the DR. There have been some initiatives in the past on this forum, see for example this thread for pViewer.

Mackx, I appreciate your information at this time, too.
Now I tried the pViewer. It was too slow but still ran.
And I didn't mean caching all of the pages but just some pages, about 5~10 or so enough to prevent buffering. Only 1 page is so insufficient, compared to any other program which buffers or pre-fetchs.
If it can't be improved, it seems that the last option would be to hide or minimize the loading dialog box.. I posted another thread about this in the past, not recently and dima_tr said he/she succeeded it in my recent thread. Now I'll ask him how..

ps. Another thing:I don't expect it, but can't we upgrade Adobe reader mobile inside DR1000S? I visited Adobe website and it seemed that the newer version came out..

[Mackx]

Originally Posted by bokjeid

Now I tried the pViewer. It was too slow but still ran.

I think it is based poppler, an open source pdf-library. It was also used in the older versions of the DR firmware (until 1.7). It is indeed slower then the abode version.

Originally Posted by bokjeid

And I didn't mean caching all of the pages but just some pages, about 5~10 or so enough to prevent buffering. Only 1 page is so insufficient, compared to any other program which buffers or pre-fetchs.

I think that the biggest problem is that pre-fetching does not work correctly any more. For sequentially reading pages (spending at least 30sec per page) caching one page would be sufficient. But then, I also read magazines which have commercial pages in them that I want to skip, so caching multiple pages would also be better for me. During the design of the pre-fetching mechanism, this kind of use-cases was probably not considered (or they found a reason to exclude this, maybe a compromise between battery usage and functionality?)

Originally Posted by bokjeid

If it can't be improved, it seems that the last option would be to hide or minimize the loading dialog box.. I posted another thread about this in the past, not recently and dima_tr said he/she succeeded it in my recent thread. Now I'll ask him how..

I have been playing with making the dialog smaller, but I bump into my limited gtk knowledge. I can get the dialog smaller, although it still has the double height that I want it to have; and I don't seem to get it moved from the centre. Any tips appreciated!

Originally Posted by bokjeid

ps. Another thing:I don't expect it, but can't we upgrade Adobe reader mobile inside DR1000S? I visited Adobe website and it seemed that the newer version came out..

It would not solve the caching issue, since that is in the 'wrapper' between the adobe-library and the uds-viewer.

[bokjeid]

Originally Posted by Mackx

I think it is based poppler, an open source pdf-library. It was also used in the older versions of the DR firmware (until 1.7). It is indeed slower then the abode version.

Yeah, I also thought it is valuable as an open source pdf-library.

Originally Posted by Mackx

I have been playing with making the dialog smaller, but I bump into my limited gtk knowledge. I can get the dialog smaller, although it still has the double height that I want it to have; and I don't seem to get it moved from the centre. Any tips appreciated!

Wow, many thanks for your effort about it!
Meanwhile, I also thought 'hiding' the dialog box would be better and easier than 'changing' it..
If it is difficult 'changing' it, the best solution seems to add an setting option to turn on/off the 'dialog box' and 'rgb-led' respectively..

Originally Posted by Mackx

It would not solve the caching issue, since that is in the 'wrapper' between the adobe-library and the uds-viewer.

I asked if the inside Adobe reader can be upgraded as totally different issue. And maybe it seems so difficult.

[Gertjan]

All dialogs are centered by the window manager (matchbox in this case), I think.

Disabling the busy dialog should be fairly easy though. Check out sysd/busy.c which has a "dialog_delay" after which the dialog is shown (default is 1 second). Increase this time or remove/disable the timeout completely.

The flashing LED is controlled from sys_update_rgb_led() in sysd/system.c.

[Mackx]

Originally Posted by Gertjan

All dialogs are centered by the window manager (matchbox in this case), I think.

Disabling the busy dialog should be fairly easy though. Check out sysd/busy.c which has a "dialog_delay" after which the dialog is shown (default is 1 second). Increase this time or remove/disable the timeout completely.

The flashing LED is controlled from sys_update_rgb_led() in sysd/system.c.

Hi Gertjan,

Thanks for the info. I changed the code in ergtk (the wait dialog is not a normal message dialog, but 'build up from scratch' in ergtk), adding an extra function allows me to create the dialog the 'normal' way or a icon-less version at the top of the screen. I further modified popupmenu-dialog.c to be able to not display the dialog. Currently the behaviour is coupled to a variable, which needs to be coupled to a gconf item and a settings-dialog to control the behaviour.
W.r.t. the led I added a 'secret' option to gconf in the lastest dr1000-hackx release allow to disabling the top-led. I also need to create a settings-dialog for this function.

[Gertjan]

Originally Posted by Mackx

I changed the code in ergtk (the wait dialog is not a normal message dialog, but 'build up from scratch' in ergtk), adding an extra function allows me to create the dialog the 'normal' way or a icon-less version at the top of the screen.

Ah okay, nice job.

I further modified popupmenu-dialog.c to be able to not display the dialog. Currently the behaviour is coupled to a variable, which needs to be coupled to a gconf item and a settings-dialog to control the behaviour.

I'd say sysd is a better place as the busy dialog is triggered there, but I'm sure your solution works.

W.r.t. the led I added a 'secret' option to gconf in the lastest dr1000-hackx release allow to disabling the top-led. I also need to create a settings-dialog for this function.

Nice. Does that disable the top led completely, or just the green 'busy' flashing?

[Mackx]

Originally Posted by Gertjan

Does that disable the top led completely, or just the green 'busy' flashing

My experimental code uses a mask on the color. Something like:
if (2^color AND mask) do not enable led, see BitBucket.
The (to be created) settings dialog would then allow to choose the colors to disable.

[bokjeid]

Originally Posted by Mackx

My experimental code uses a mask on the color. Something like:
if (2^color AND mask) do not enable led, see BitBucket.
The (to be created) settings dialog would then allow to choose the colors to disable.

I don't know about programming at all but it sounds really fantastic..!
I think every person agrees that you're a re-creator of DR1000S!!

[Iñigo]

Originally Posted by Mackx

I have been playing with making the dialog smaller, but I bump into my limited gtk knowledge. I can get the dialog smaller, although it still has the double height that I want it to have; and I don't seem to get it moved from the centre. Any tips appreciated!

Sorry, haven't read the details of your problem, but explain it to me and I'll try to help. Or send me an email with the issue.

Iñigo

[Mackx]

Originally Posted by Iñigo

Sorry, haven't read the details of your problem, but explain it to me and I'll try to help. Or send me an email with the issue.

I solved most of the problems, I only have one issue with the height at this moment. We can discuss this later when I have pushed to code to BitBucket.

[bokjeid]

If minimizing the dialog also gets available, there might be, in a result, 3 setting options for the dialog:'on', 'off', 'minimized'.