i was using the sony browser on my t1 and i left it alone for something like 5/10 minutes cause i had to do some stuff,when i picked it back something odd happened: the screen did not refreshed, like when you scroll a webpage and the screen enter a low definition mode to avoid continuous flashing due to e-ink refresh; i tried using some app (adw launcher,rssdemon,dolphin browser mini etc.) and saw it was applied globally!

Maybe this non refresh mode can be activated outside the stock browser for the other apps,i think it would be really useful

i made a video (and discovered that returning to the home deactivated the trick )

Nice find! I figured out how to replicate this. When scrolling with the default web browser there's a delay before it resets. Just scroll with the browser and then quickly tap the top of the screen to open the notifications bar. It will keep it from resetting and enter it in a semi-permanent partial refresh state. Going to the Sony homescreen or opening an ebook with the Sony Reader app resets it back to normal.

This partial refresh trick is actually really helpful for whenever you need to scroll through lists like Dropbox and the file manager.

It also works with FBReader for perma-partial page refresh. It doesn't look too bad but the text is definitely rougher than usual. It makes page turns faster, especially when holding down.

I also ran into this several times, but it turned everything to 1-bit black&white, i.e. no grey scale anymore....

But as far as I remember there are driver settings (either at /sys or /proc) that determine at which ratio of changed screen content there will be a full refresh. And these settings should be tweakable! Just need to find the time to do more research....

Indeed, that works perfectly... you've definitely less pixels (and details), but that's logically...

If someone has some time to dig in deeper, maybe it would be possible to activate some "switch"-script by pressing the home or menu button for e.g. 2 seconds (which then activates/deactivates the refresh mode)
=> but we can already use it sometimes (when you know you're going to scroll to much, and when there is some wifi-connection :-) )

Indeed, that works perfectly... you've definitely less pixels (and details), but that's logically...

If someone has some time to dig in deeper, maybe it would be possible to activate some "switch"-script by pressing the home or menu button for e.g. 2 seconds (which then activates/deactivates the refresh mode)
=> but we can already use it sometimes (when you know you're going to scroll to much, and when there is some wifi-connection :-) )

You don't need an active Wi-Fi connection on a Rooted T1; you can launch the Browser from Zeam without one, pinch, and click the bar in an instant.
I got it to work on my very first try.

The setting survives sleep mode, BTW, and switching to other non-Sony apps. And yes, it looks like it switches to a pure B&W mode; Coolreader and Kindle work fine. Aldiko, not so much.
But paging in all three apps is ridiculously fast--no black flash at all, for those that care--so if a 2-bit mode could be enabled via a software switch, it should still be a major speed boost with no significant text quality loss.

I'm thinking there should be a way of attaching a method to change modes to the global TouchDown/Up methods (if they exist!) and that there should be some clue in the browser code.

So I've extracted the browser code and found this file Here which has a lot of hopeful variables in it like INVALIDATE_DELAY_FOR_CHANGE_EINK_MODE and methods like startTouch etc, although as I've not done any android dev or whatever this ddx is before it's all a bit foreign at the moment.

Interface has been implemented in ViewGroup - so any view which implements AbsoluteLayout has access to those methods.

Sony's browser WebView keeps current updateMode in a class variable and updates it when necessary (touch, zoom with eInk mode constants). All calls to invalidate are using this "new" framework functions - the rest happens automatically.

Interface has been implemented in ViewGroup - so any view which implements AbsoluteLayout has access to those methods.

Sony's browser WebView keeps current updateMode in a class variable and updates it when necessary (touch, zoom with eInk mode constants). All calls to invalidate are using this "new" framework functions - the rest happens automatically.

Something like that...

Just checking in to confirm this. My experiments show that update mode 4 is flashy, 5 is b/w and fast (and I guess not as easy to get out of as the other ones?) and 2 or 3 may be suitable for "normal" use.

I made an "EinkListView" class when experimenting, which is just a ListView that overrides all the methods that have updateMode overloads in Sony's android.view.View to use the updateMode ones:

In order to see more e-ink friendly applications and to get app designers on board, we need a replacement class for the usual WebView.

It should simply be a matter of overriding the methods that have updateMode overloads - basically, copying the methods in the EinkListView I posted about except the constructors and then adding the WebView constructors and an mUpdateMode variable. Then the update mode can be controlled by changing the mUpdateMode variable.

Quote:

Being not an Android programmer, I looked around for generic code which could make it in such a replacement. So far I found these:

Cool reader has very low page turn flicker, the second code I could not see in action.

In an e-ink friendly app, there would be an option to select high-contrast skins and optimize page refreshes.

Once the keyword "e-ink" or "e-ink friendly" will show up in the Android Market, then we've got the ball rolling.

The Cool Reader code looks like it does some device specific hardware magic to turn of the flashing, and the aardict code seems to be generic "page up"/"page down" code (i.e. it reduces superfluous flicker due to scrolling animations, but does not affect the way the screen behaves).

I guess the former is what everyone would like to be able to do, and the latter is something that should be the very minimal effort expected from a developer of an app if it is to be called E-ink friendly (i.e. avoiding animations of all kinds, aiming instead for static screens whenever possible).

Luckily, Sony has provided us with a higher level interface with the "update modes" in the android.view.View class, so on the PRS-T1 a non-flickery app doesn't have to worry about the hardware as long as it utilizes the update modes. It still goes in the former category though, since the methods are device-specific.

Anyhow, the source code for my ListView experiment is available at SourceForge if anyone wants to take a peek, and an APK is available here.