MobileRead Forums - View Single Post

charleski · 06-17-2011, 10:16 PM

Ok, the partial screen refresh was a decent idea that just needs a bit of work. Speeding-up page-turns makes a lot of sense in some scenarios, but not in others, and it's pretty simple to modify the logic to account for this.

Let's look at the desired outcomes and work back from there:
1) When people are reading normally, they want the text to look as good as possible.
--> Perform a full screen refresh on forward page-turns that occur above a certain threshold. This threshold could, optimally, be related to the size of the font (a longer time for smaller fonts) and could be adjustable to allow for individual differences in reading speed.

2) When people are flipping through a book looking for a certain passage, they want the pages to turn as quickly as possible. This is something I do quite often. The slow speed of eInk page changes can become very annoying, and is something that is far easier in paper books. This is where you want to implement a speed-up in page-turning.
--> When page-turns occur below the threshold, only do a partial refresh. At some point you will need to perform a full refresh of the page, but that point can be varied (within limits) by the rate at which page-turns are requested. If you see a flurry of page-turns which suddenly ends, it's probably a good idea to perform a full page-refresh at that point since this implies the reader has found the section they wish to read (it's probably a good idea to display a banner announcing the refresh at this point).

3) Intermediate states: If the reader does a page-forward and then soon after does a page-back, then another page-forward, they're probably just making sure they caught the full sense of a sentence that has carried on from the previous page.
--> So do a partial refresh on the page-back and then a full refresh on the second page-forward.

These states can all be modified by a global refresh counter. But this should be modifiable by the user, so they can specify the number of partial refreshes they would tolerate for text that they're reading normally.

06-17-2011, 10:16 PM	#1
charleski Wizard Posts: 1,196 Karma: 1281258 Join Date: Sep 2009 Device: PRS-505	How to do Partial Refreshes Ok, the partial screen refresh was a decent idea that just needs a bit of work. Speeding-up page-turns makes a lot of sense in some scenarios, but not in others, and it's pretty simple to modify the logic to account for this. Let's look at the desired outcomes and work back from there: 1) When people are reading normally, they want the text to look as good as possible. --> Perform a full screen refresh on forward page-turns that occur above a certain threshold. This threshold could, optimally, be related to the size of the font (a longer time for smaller fonts) and could be adjustable to allow for individual differences in reading speed. 2) When people are flipping through a book looking for a certain passage, they want the pages to turn as quickly as possible. This is something I do quite often. The slow speed of eInk page changes can become very annoying, and is something that is far easier in paper books. This is where you want to implement a speed-up in page-turning. --> When page-turns occur below the threshold, only do a partial refresh. At some point you will need to perform a full refresh of the page, but that point can be varied (within limits) by the rate at which page-turns are requested. If you see a flurry of page-turns which suddenly ends, it's probably a good idea to perform a full page-refresh at that point since this implies the reader has found the section they wish to read (it's probably a good idea to display a banner announcing the refresh at this point). 3) Intermediate states: If the reader does a page-forward and then soon after does a page-back, then another page-forward, they're probably just making sure they caught the full sense of a sentence that has carried on from the previous page. --> So do a partial refresh on the page-back and then a full refresh on the second page-forward. These states can all be modified by a global refresh counter. But this should be modifiable by the user, so they can specify the number of partial refreshes they would tolerate for text that they're reading normally.