iLiad xepdmgr - another approach to auto-refresh

[ericshliao]

Hi, Antartica.
I am having a very interesting problem (experience) with eink refresh under FBReader.
I am using FBReader 0.12.1 on iLiad. I also made a patch to enable vertically displayed Chinese text. When FBReader enters vertical-displaying mode, xepdmgr won't generate full-refresh anymore (typing refresh is generated instead).
My patch is quite simple. I just call some Pango function to change font gravity to EAST and ask FBReader to rotate the screen 270 degree.
I upload two video, one (the second video) is normal refresh under normal FBReader, and the other (the first video) is strange refresh under vertical-displaying mode of FBReader. The quality of the two videos is only QVGA, but you can still see the difference of full refresh and typing refresh.

Added:
The problem only exists for xepdmgr 1.9i. If I use 1.9h, there won't be such problem.

Added 2:
Personally, I like typing refresh because there is no black flash in the mode. The bad thing is that the screen gets dirty after 3 or 4 accumulated refresh. If xepdmgr can do a full refresh after 3 typing refresh, accumulated typing refresh is still acceptable. So, it occurs to me that maybe adding an option to use all typing refresh and do a full refresh after 3 typing refresh is worth trying.

[ericshliao]

When I was thinking how to mod FBReader to preload next page in background, an interesting idea came to me. I think it can make preloading next page feasible even without thread in FBReader. Although I am making some progress on adding thread-capability to FBReader, I am still not certain if I can make preloading on FBReader. In comparison to adding thread-capability to FBReader, this idea seems very easy to implement.
I call this idea "delayed refresh". It's an iLiad-only idea and can only be achieved with the aiding of xepdmgr. The essence of the idea is "cheating readers"!
Read on and you'll know why preloading can be achieved by "cheating reader".

The details of the idea is:
1. After the first page is loaded by FBReader and displayed, de-activate xepdmgr temporarilly (by adding code to FBReader).
2. Then generate a page-flip signal to FBReader (by adding code to FBReader). Thus, FBReader will load the next page, but it is not shown on screen since xepdmgr is de-activated. In fact, FBReader is already flipped to next page, but the result is not shown on screen.
3. When the user has finished reading the first page, and push the next-page button, immediately re-activate xepdmgr (by adding code to FBReader), and immediately stop FBReader for 500ms (by adding code to FBReader) for xepdmgr to finish its job. Xepdmgr will refresh to show the next page. The speed will be fast since FBReader has already prepared the next page and refreshed the UI widgets. The reader will see screen refreshing in 3 secs after page-flip button is pushed.
4. De-activate xepdmgr before FBReader resumes its normal routines (by adding code to FBReader). Thus, FBReader will load next page but the result will not shown immediately (just like step 2).

I remember that xepdmgr provides some functions for applications to control screen refresh manually, but I never seriously tried. Maybe it's a good time to try it now.

Do you have any comments on the theoretical "delayed refresh" idea?

Added:
Some special care must be added. For example, actions other than pushing next-page button done by users, such as change font-size, scroll backward, open library, change options, will immediately re-activate xepdmgr.

[lunohod]

Originally Posted by ericshliao

When I was thinking how to mod FBReader to preload next page in background, an interesting idea came to me. I think it can make preloading next page feasible even without thread in FBReader. Although I am making some progress on adding thread-capability to FBReader, I am still not certain if I can make preloading on FBReader. In comparison to adding thread-capability to FBReader, this idea seems very easy to implement.
I call this idea "delayed refresh". It's an iLiad-only idea and can only be achieved with the aiding of xepdmgr. The essence of the idea is "cheating readers"!
Read on and you'll know why preloading can be achieved by "cheating reader".

The details of the idea is:
1. After the first page is loaded by FBReader and displayed, de-activate xepdmgr temporarilly (by adding code to FBReader).
2. Then generate a page-flip signal to FBReader (by adding code to FBReader). Thus, FBReader will load the next page, but it is not shown on screen since xepdmgr is de-activated. In fact, FBReader is already flipped to next page, but the result is not shown on screen.
3. When the user has finished reading the first page, and push the next-page button, immediately re-activate xepdmgr (by adding code to FBReader), and immediately stop FBReader for 500ms (by adding code to FBReader) for xepdmgr to finish its job. Xepdmgr will refresh to show the next page. The speed will be fast since FBReader has already prepared the next page and refreshed the UI widgets. The reader will see screen refreshing in 3 secs after page-flip button is pushed.
4. De-activate xepdmgr before FBReader resumes its normal routines (by adding code to FBReader). Thus, FBReader will load next page but the result will not shown immediately (just like step 2).

I remember that xepdmgr provides some functions for applications to control screen refresh manually, but I never seriously tried. Maybe it's a good time to try it now.

Do you have any comments on the theoretical "delayed refresh" idea?

Added:
Some special care must be added. For example, actions other than pushing next-page button done by users, such as change font-size, scroll backward, open library, change options, will immediately re-activate xepdmgr.

It seems that you are trying to implement something like I did a while ago for OI. Take a look at this commt:
http://git.openinkpot.org/fbreader.g...aada6ea3451bd4

[ericshliao]

Originally Posted by lunohod

It seems that you are trying to implement something like I did a while ago for OI. Take a look at this commt:
http://git.openinkpot.org/fbreader.g...aada6ea3451bd4

Thanx for the hint.
Basically, the ideas are very similiar. Your previous work helps a lot. Now, at least I know the first file to study is "FBReaderActions.cpp" if I am going to implement the "delayed refresh" idea.

Added:
FBReader have been under large overhaul in the recent year. No more "FBReaderActions.cpp", I have to look into "ScrollingAction.cpp".

[lunohod]

Originally Posted by ericshliao

Added:
FBReader have been under large overhaul in the recent year. No more "FBReaderActions.cpp", I have to look into "ScrollingAction.cpp".

Oh, sorry. I've also moved my changes to the ScrollingAction.cpp:

http://git.openinkpot.org/fbreader.g...lingAction.cpp