DR800 I would need 2 more infos about the reader..

[repods]

Originally Posted by luite

uds is used to open most types of files, including pdf. you can find which application is associated with which file type by executing one of the following commands on the emulator:
# gconftool-2 --dump /apps/er/sys/ctb
# erconftool -s /apps/er/sys/ctb
(this shows the gconf configuration for ctb, the content browser program)

I was not asking that, I was asking something on panning mode..

in any case, I found an easy and legal way to enable continuous mode and full screen on dr800..
continuous mode works wonderful in landscape mode, but in portrait mode there is the double refresh issue..
for this reason I want even to change the behaviour of the flip bar in panning mode: when the last part of the page is shown, and the flip bar is pressed again, the beginning of the next page must be shown..
I intend to write an app. for easy continuous and full screen management, but I have no idea of how to do..
expecially the graphical part (how I can do for example those stylus check boxes that are used under settings ?)..
if someone want to help.. that is appreciated..

[Mackx]

Originally Posted by repods

I intend to write an app. for easy continuous and full screen management, but I have no idea of how to do..
expecially the graphical part (how I can do for example those stylus check boxes that are used under settings ?)..
if someone want to help.. that is appreciated..

Did you have a look in the sources for the settings app from iRex? See here on the iRex Developer site. The settings-4.0+svnr6834.tar.gz file contains the source code of the settings application that is running on your DR.

[repods]

Originally Posted by Gertjan

1. the applications access metedata.db via calls to libermetadb.
2. applications register menu items and toolbar icons via popupmenu which calls back to the application over IPC
3. they are key presses
4. the platform uses DBUS for IPC via glib-dbus and liberipc.

Please check the iOn development document carefully as it should answer a lot of your questions.

thank you for your previous answers Gertjan
I would need some other informations

1-when opening a book uds cache pages ?
2-the cache is held in memory or there is a file inside the filesystem ?
3-is correct that no swap partition or file is used by the reader ?

[Iñigo]

Originally Posted by repods

thank you for your previous answers Gertjan
I would need some other informations

1-when opening a book uds cache pages ?
2-the cache is held in memory or there is a file inside the filesystem ?
3-is correct that no swap partition or file is used by the reader ?

The emulator is your friend. Some of the questions you are asking can be easily answered by yourself with a bit of work.

1. iLiad did, so I suppose DR too.

2. Look at the attached file. It's the output of strace running against uds while viewing a .pdf file in DR800 emu. I can't see any strange file opening.
It could talk with sysd using dbus in order to delegate the caching, but I doubt it.
So my assumption is that page cache is handled in memory.

3. You can check yourself with "swapon -s" in the emulator => no


Look at lines 1467-1505 and tell what do you think
The fd 8 is a dbus connection.

[Gertjan]

Originally Posted by repods

1-when opening a book uds cache pages ?
2-the cache is held in memory or there is a file inside the filesystem ?
3-is correct that no swap partition or file is used by the reader ?

1. UDS does not cache, the UDS plugins do. The Adobe plugin (PDF/EPUB) tries to predict navigation and prerenders and caches pages accordingly, as memory permits.
2. the current plugins cache in memory only.
3. that is correct.

[repods]

Originally Posted by Gertjan

3. that is correct.

thank you for the answers..
1-do you think that enabling swap in some way could speed up the operations of the reader ?

[yacoob]

Unless the system is running out of memory, adding swap won't change a thing. If it is running out of memory, swap would allow the device to survive (ie. kernel won't kill some processes) but usually access time to flash device is larger than to RAM.

[Gertjan]

Originally Posted by repods

1-do you think that enabling swap in some way could speed up the operations of the reader ?

There is only one way to be sure. Try it and let us know

Seriously though, the devices have enough memory to keep the applications and several (large) documents open. Increasing cache would only be noticeable when you would browse pages (back and forth) a lot, which is not a typical use case.

As yacoob says, flash is not known of its quick throughput and it has endurance limits which makes it not particularly suitable for use as cache.

[repods]

Originally Posted by Gertjan

There is only one way to be sure. Try it and let us know

Seriously though, the devices have enough memory to keep the applications and several (large) documents open. Increasing cache would only be noticeable when you would browse pages (back and forth) a lot, which is not a typical use case.

As yacoob says, flash is not known of its quick throughput and it has endurance limits which makes it not particularly suitable for use as cache.

mmm..
I think that the thing need to be tested..
most likely the advantage can be just in page rendering time..
and that would be a very good thing..
as you and all users have for sure noticed when you open a large pdf document the next 2-3 pages after the one you are reading get shown immediately if you go on quickly..
the forth one requires the pause with the popup messagebox ..
so this means that the first ones have been already rendered and are ready to show in cache.. the other ones need still to be read and rendered..
so think if we have a cache where all the page of the book are already rendered.. even if this cache is not on the physical memory..
most likely the bottle neck is not on the disk access time but on the cpu computational time.. pdf is not simple to render and the cpu of the reader is not a quadcore for sure..
so while you read your page the reader could have the time to pre-render all the rest of the book..
so the thing have to be tested..
so some more questions..

1-do you think that the access time would be faster on the rom or on the sd card ? on the rom there is 58 mb of free space.. while on the sd there is a lot of space.. obviously that test should be done with a large swap on the sd card, but I'm curious the same about this..
2-how much physical memory has the device ?
3-if a swap is enabled, the cache in uds would be enlarged automatically or some tweak need to be done somewhere ? and where ?

@yacoob
well you are right too

[Gertjan]

Originally Posted by repods

1-do you think that the access time would be faster on the rom or on the sd card ? on the rom there is 58 mb of free space.. while on the sd there is a lot of space.. obviously that test should be done with a large swap on the sd card, but I'm curious the same about this..
2-how much physical memory has the device ?
3-if a swap is enabled, the cache in uds would be enlarged automatically or some tweak need to be done somewhere ? and where ?

1. SDD access tends to be quicker than the internal flash but it depends on the SD card used. Again, testing is the only way to find out.
2. I'm happy to support community development, but it would help if you tried to find answers before asking around. The amount of RAM is on the spec sheet: http://www.irextechnologies.com/irexdr800/specs
3. as said, the cache is in the plugin. The plugin tries to predict navigation, and prerenders and caches pages accordingly, as memory permits. With more memory, it might keep more pages in cache but it all depends on the navigation and number of open documents. You cannot tweak the caching algorithm as it is in Adobe plugin which is closed source for licensing reasons.