WebView Java code for e-ink devices

[bardo]

Normal e-ink operation is slow, display updates result in black intermediate flashes, for scrolling there are multiple flashes.

In order to control the refresh behavior, WebView and other classes in E-ink devices have an added parameter.

The fast e-ink mode results in fast display updates, but leaves some ghosting from previous contents, plus the contrast is somewhat reduced. It appears that it leaves only ghosting from not fast mode, so a clear before entering fast mode might fix it.

Since so far e-ink Androids only (?) exist as rooted versions of bookshop frontends (Kindle, Nook, Sony, ..), there is no official documentation available.

hberntsen on https://www.mobileread.com/forums/sho...=165376&page=2 proposed a way to control the update behavior. His app code tries to inject the update parameter with a wanted value by try/catch (no need to identify the device first).

As an example application how to change the update mode inside an application, see
http://code.google.com/p/ankidroid/issues/detail?id=971
See the attached code for the adapted WebView class.

At the moment, the fast e-ink mode only gets reset when running a stock (Sony PRS-T1 for me, I guess it is the same for the Nook) application.

The actual meaning of the updatemode parameter values is not well understood.
E.g. I would like to switch back to normal mode, but calling
MyWebView.mUpdateMode = 34;
additionally does a full page refresh. How to do it without?

[rupor]

Just my 2 cents:

If eInk screen could be made to behave the same way as LCD - it would've been made already saving you a lot of time Just think about it - do you really believe that people who modified Android for eInk platform are that bad?

Doing what you actually want properly requires big Android redesign and reimplementation and even than result may not satisfy you anyway. eInk is different - no matter how hard you will try to switch controller modes. Looking for magical value is pointless. Today if applications you are using are not designed for eInk - result would not be good.

Doing decent work on application level however is entirely possible - and that is what WebBrowser demonstrates and platform supports.

From what I could see By default driver/controller are in AUTO mode - drawing using fast and dirty modes do not require switching. WebBrowser controllably switches in FAST ANIMATION mode (A2) during zoom and scroll and full refresh (UpdateMode = 34) is used to switch controller back and requires delayed full refresh (800 ms according to original WebView code). Otherwise controller stays in A2 mode (rather than AUTO - default mode) and you would immediately see this on your screen. If you want to avoid full refresh - do not use A2 mode and draw using dirty modes (DU,GC4,GC16) instead - as I said they are compatible with AUTO. Driver and controller support drawing of up to 16 regions on the screen - each with it's own mode - simultaneously. When you go over some complexity threshold - full refresh will happen anyway as controller cannot handle it.

This information is all over Web - on FreeScale web site, Nook forums and in Sony code...

[bardo]

Hi Rupor,

> This information is all over Web - on FreeScale web site, Nook forums and in Sony code...

Can you pls provide links to these docs?

Specifically, regarding my question: what would be a "good" sequence to switch from fast to auto mode? - Without changing the firmware, but using the method of hberntsen and changing the mUpdateMode parameter.

What is the WebBrowser code?

[rupor]

EbookWebBrowser.apk - simply bacsmali it. Take a look at WebView.smali - since you were talking about "34" and refresh I though you are already familiar with what Sony does.

Take a look at those slides for example - they are freely available.

I already described sequence known to me - I have nothing to add to what I already said. I tried to explain why any method of global changes is just a demo (IMHO) and would never be practical - I hope I understood your question properly.

What reasons do you have to believe that if such method existed it would not be used in a stock firmware produced by people who have time and documentation? Can you share your thoughts on this?

[bardo]

What reasons do you have to believe that if such method existed it would not be used in a stock firmware produced by people who have time and documentation? Can you share your thoughts on this?

Amateurs sometimes reinvent the wheel - and like it

A month ago I got my PRS-T1, a week ago I did my first compile on Android, quite a learning curve.. Thanks for the info on bacsmali, the Freescale slides give excellent e-ink programming background info.

I try to find out what apps can make sense on an e-ink device, what modifications are needed to make it e-ink friendly. Some mods I learned:

• General: Open apk with 7zip or others, change icons and bitmaps to high BW contrast, re-sign apk.
  
• AardDict offline Wikipedia: changed from scrolling to paging and added DairyKnight's N2EpdController.
  
• Anagram, AnkiDroid (flashcard learning): no scrolling, but higher frequency of page content change, even N2EpdController flashes too much and the reaction time is too slow. Switching to fast/ghosting grey mode is OK for the flash cards, but I need to learn more how to switch back and forth between the modes without triggering too much flashing.

I want to see more e-ink friendly apps. But most developers do not know about e-ink, they need our support and ready-made replacements for their say, WebView calls. Thats why I consider hbertsens approach an important contribution.

A big to you and this forum for sharing your knowledge.

[bardo]

The thread title might give a wrong impression, it should have read:
WebView Java code for easy adaptation of apps to e-ink devices