make scrolling and page turns e-ink friendly

[bardo84]

On e-ink devices scrolling creates a lot of screen refreshing action and annoying flicker.

It would be nice to adapt the scrolling (via swipe gestures) and page turns (via volume up and down) for e-ink devices.
Don't know the details but it would reduce the page refreshes/ animations to an absolute minimum.
Then reading on your app becomes really fun.

Thanks!

[itkach]

Honestly, I have no idea what would be involved in making that happen. Aard Dictionary uses standard WebView component and doesn't implement it's own scrolling and scrolling animation. One would think that vendor who puts Android on an e-ink device should do the adaptation of all the standard components to replace animations designed for regular screens with something that works for e-ink.

Volume up/down already scrolls using WebView's standard page up/page down. Does that also flicker a lot?

[bardo84]

Yes, it does. Looking around on the web I find a recurring theme "we had to rebuild WebView from scratch to adapt it to the e-ink display" One more detailed info (about a component called WebKit here) is from http://www.collabora.com/services/case-studies/irex :

The Digital Reader's special e-paper display led to new challenges. To adapt WebKit to electronic ink displays, and to reduce eyestrain and power usage, Collabora's developers added code to reduce the number of refreshes, allow a book-like page by page view of web pages, and show useful and meaningful placeholders instead of animated content.

Collabora developer Marco Barisione gave a talk
http://archive.fosdem.org/2009/schedule/events/xd_webkit_ebook
on the iRex project at FOSDEM in February 2009. You can download his presentation slides
http://people.collabora.co.uk/~bari/slides/
And you can download code from this project here:
http://developer.irexnet.com/pub/iOn/

Hope this helps. If we can identify and replace the culprit, there is hope that many more apps can be made e-ink friedly.

[bardo84]

Here are some links to code how other applications do it. Maybe their display engine could give hints for flicker-free scrolling and page turns:

github.com/kobolabs/Kobo-Reader
github.com/amahule/CoolReader
github.com/geometer/FBReaderJ

[bardo84]

Hi,

I contacted the author(s) of cool reader on their implementation of
smooth scrolling on e-ink devices and got the following reply:

support@coolreader.org
Hello,
Look at N2EpdController.java

Author is DairyKnight from xda-developers. At least you can use it under GPL.
For use in closed project I would recommend to contact him.
Best regards,
Vadim

2012/1/14 itkach
reply@reply.github.com:

Honestly, I have no idea what would be involved in making that happen. Aard Dictionary uses standard WebView component and doesn't implement it's own scrolling and scrolling animation. One would think that vendor who puts Android on an e-ink device should do the adaptation of all the standard components to replace animations designed for regular screens with something that works for e-ink.

Volume up/down already scrolls using WebView's standard page up/page down. Does that also flicker a lot?

---

Reply to this email directly or view it on GitHub:
#28 (comment)

[itkach]

I don't see how any of this can be used in aarddict.

[bardo84]

Looks like a not so easy task.

Ideally, display components for e-ink devices should be part of the Webkit's WebView framework. I've submitted a feature request via
bugs.webkit.org/show_bug.cgi?id=76429

Alternatively, you could get in touch with dairyknight (dairyknight@gmail.com) for his N2EpdController
as used in
code.google.com/p/apv/source/browse/pdfview/src/cx/hell/android/lib/pagesview

[bardo84]

itkach,
just saw you are related to the FBreaderJ project.

The developers actually did implement flicker-free partial page refresh in their app:
http://forum.xda-developers.com/showthread.php?t=1183173

You might get support from
Nikolay Pultsin: geometer@fbreader.org
Arseny Shmartsev, CEO of Geometer Plus LLC: ars@geometerplus.com
Support: support@geometerplus.com

[max-kammerer]

I use next code for my nook port of aarddict:

// from kbs - trook.projectsource code.

private final void pageUp() {
        int cury = articleView2.getScrollY();
        if (cury == 0) { return; }
        int newy = cury - WEB_SCROLL_PX;
        if (newy < 0) {
            newy = 0;
        }
        articleView2.scrollTo(0, newy);

}

private final void pageDown() {

        int cury = articleView2.getScrollY();
        int hmax = articleView2.getContentHeight() - 200;
        if (hmax < 0) {
            hmax = 0;
        }
        int newy = cury + WEB_SCROLL_PX;
        if (newy > hmax) {
            newy = hmax;
        }
        if (cury != newy) {
            articleView2.scrollTo(0, newy);
        }

}

[bardo84]

Hi Max,

thanks for sharing, does this reduce the page refresh flicker?
Is this method special to the Nook or will it work on other (e-ink) devices like the PRS-T1?

[max-kammerer]

It just scroll page to target location without animation )
It should be applicable for all devices

[tristan-k]

Is there a apk-package available for eink-devices like the prs-t1 which implement the changes of max-kammerer?

[itkach]

All e-ink related patches submitted to me were accepted and are incorporated into the application. There is no separate apk. Special article view for e-ink displays should be used automatically when e-ink display is detected, at least on some devices. I can't comment on how well this works not having any e-ink devices myself.

[max-kammerer]

According to code supported devices are only the SONY PRS-T1 and Nook ST:
EINK_NOOK = MANUFACTURER.toLowerCase().contentEquals("barnesandnoble") && MODEL.contentEquals("NOOK") && DEVICE.toLowerCase().contentEquals("zoom2");
EINK_SONY = MANUFACTURER.toLowerCase().contentEquals("sony") && MODEL.contentEquals("PRS-T1");
EINK_SCREEN = EINK_SONY || EINK_NOOK;

But it's seem that it is easy to add other devices

[tristan-k]

So the changes are live in the current version available on the google playstore market? I do use a PRS-T1.

[itkach]

So the changes are live in the current version available on the google playstore market?

Yes, but since you ask I assume it doesn't work for you?

[dmak]

What about adding PRS-T2? Should be really a quick-fix. Perhaps you can replace a check with MODEL.startsWith("PRS-"); as I doubt that later Sony PRS products (if will be announced at all) will transform into non-eInk.

[itkach]

What about adding PRS-T2? Should be really a quick-fix.

Quick fix it may be, but somebody needs to test this and I don't own PRS-T2 or any other e-ink readers. Any volunteers?

I doubt that later Sony PRS products (if will be announced at all) will transform into non-eInk.
I would rather not make changes based on pure speculation.

[dmak]

I can test.

I would rather not make changes based on pure speculation.

Well, it is not sure speculation. Indeed it is a guess, but on the other hand I don't know any example of eInk-series that have been turned to e.g. TFT without changing the name of the series :)

Indeed there are other PRS- readers, check here, and all before PRS-T1 are not Android-based (out of the game). You have to decide, of course, if you want to add T1, T2, … one-by one or treat as one big family. What can go wrong on, let's say, Sony PRS-T3? If it works, you don't need to change anything, if it fails there would be a ticket (with possibility to use not-the-latest-version).

Let's have a look at critical code, I am also interested. Where it can fail? In N2EpdController#setGL16Mode()? You can always fallback to normal screen if UI initilization fails in LookupActivity#initUI(), just don't refer DeviceInfo.EINK_SCREEN statically.

[itkach]

What can go wrong on, let's say, Sony PRS-T3

Imagine we would enable e-ink display for Kindle with a check like MODEL.startsWith("Kindle"). What could possibly go wrong indeed.

I can test.

Test, submit patch.