View Single Post
Old 06-10-2013, 06:36 AM   #70
jackastor
Wizard
jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.jackastor ought to be getting tired of karma fortunes by now.
 
jackastor's Avatar
 
Posts: 1,847
Karma: 3212428
Join Date: Jun 2011
Device: iphone stanza, kobo touch,ASUS TF300,KOBO GLO, Kobo Aura HD, Kobo Mini
Quote:
Originally Posted by TechniSol View Post
Theonna,

I'm all for improvements, but I think it unrealistic to expect a major paradigm shift in the core of the software.

The database is a rational approach in that the information must only be collected once, not every time the system is booted, or files are looked for. This should result in less time overall for various tasks to be performed as in theory the information must only be collected once and only updated as changes occur.

The real questions when one runs into over long pauses are what are they doing, and why is it taking so long? As fast as the processor is, one must wonder what takes so long for large shelves to be displayed. My guess is they are processing all of something rather than just enough to start displaying the first page and continuing to process in the background while allowing the relatively feeble human to see and injest that first page. Even a slow system should stay ahead of a human as long as there is no ability to jump far ahead, and even then should only bog down for the time to process one page and display it.

With such an approach the lag time becomes shelf length independent and relates directly to the processing time necessary only to process/display one page of the shelf. I have few shelves, and only enough items on them to require a few pages to display the entire shelf.(OK, one with 99 items, but it's quick too) My shelves display quickly. I think they would only require a bit of re-coding to achieve this(if they don't have it already), as long as it is possible to run a second task in the background to continue whatever processing they are consuming so much time with. They might even find the most efficient use of that task would be to only process a few pages ahead, rather than the whole shelf if that would keep up well ahead for most casual browsing and minimize power requirements. I would think an algorithm based on percentage would be most efficient so that as shelves grow ever larger the same percentage of pages are processed ahead by the background task rather than a set number of pages.
You know we all talk about the processor speed. But I wonder if the processor is scaled down and not running as fast as it could to bring the extended battery life. Now on that note, the desktop software that Kobo supplies is next to useless. It seems to me that it should no ifs or buts about it handle all our ebooks from epubs to kepubs etc. and Create the data base for the kobo device. Thus using full computer power to speed this issue up including the rendering of covers. And then send it to the unit. Seems a common sense thing to do.

Regards

Jack
jackastor is offline   Reply With Quote