robko: as voom suggested, I'm talking about the text file reader. I realise this isn't a core part of the product but it just happens to be what i've been using so far. Changing font size is a real pain there too.
Quote:
Originally Posted by BWinmill
Out of curiosity: what are you using for the JVM? And how do screen updates with the JVM compare to Kobo's software? (I'm wondering if there's a way to optimize screen refreshes for eink devices.)
|
I'm using oracle's ARMv7 embedded javase 7, the headless one.
http://www.oracle.com/technetwork/ja...ase/index.html (you need to register of course & cannot distribute).
The screen updates are similar for the most part, but:
a) If the source data is monochrome (or you ask the device to map it to monochrome) the updates are a fair bit faster, and leave less 'crap' behind. It looks fine enough for widget pages (e.g. try the page-setting slider whilst reading, which does this), and IMHO (with my eyes and a decent font) is fine for reading as well.
b) Again for widget pages, one can get away with quite a few updates without inverting the ink which speeds it up a bit too (and makes it nicer to look at).
c) remove all shading and styling from buttons: otherwise updates are very slow and ugly. inverting buttons to high-light is the fastest.
The main issue with the kobo software is the pauses and delays outside of the e-ink updates which interfere with the interactivity. For one it seems to love searching for and reading 'Kobo.conf' hundreds of times a second every now and then. Other delays seem toolkit related: e.g. try to set the date or time. Turning pages is about as fast as the e-ink will go though.
ikarus99: The code is a bit of a hack, but since I have a bunch of google code stuff already I will dump it there soon, check my blog for that. My blog about it is at
http://a-hackers-craic.blogspot.com/search/label/kobo
The screen refresh is mostly pretty simple: update rectangle. But finding where that rectangle is can be a pain if you're retro-fitting an existing toolkit. I've played with the various ioctl options but most don't seem to make a noticeable difference. Doing an 'invert' will clean up the artefacts (as is obvious from using the reader). Now, if only I can work out how to resume from a suspend ...
I detest C++ so I wont be going there even if kobo provided a full sdk for it. I'm more interested in the journey than the destination so i've no real plans other than poking for fun.