Anelok: weird ways to scroll

Werner Almesberger werner at
Mon Jan 19 13:29:15 UTC 2015

EdorFaus wrote:
> Frankly, I think it would be clearer (at least to me) if the cursor
> and/or list just jumped one item at a time without the smooth scrolling
> in between. A bit old-fashioned, perhaps, but still clearer IMO.

I didn't do this just to be fashionable ;-) What I'm after here is
to have immediate visual feedback - to compensate for the lack of
tactile feedback.

> Mode 1, on the other hand, doesn't really seem odd at all.

Great !

> I had an idea for a marker that might work, without inverting the entry
> or otherwise causing long white lines, though I'm less sure about the
> clutter aspect. The marker would be a vertical line right next to the
> item, exactly one item high, and following the item like the cursor does
> now - with the cursor pointing at it, possibly touching it.

That sounds pretty intuitive and not too clutterish. When I thought
of a concept to describe the behaviour, I thought that it's a bit like
the "blur" used in comics to show movement.

Now, this gave me another idea: the cursor triangle could move pixel
by pixel, but leave a "blur" from / to the center of the current
entry. That may look even cuter and wouldn't consume horizontal

> This kind of solution would also have the advantage of showing how close
> you are to switching which item is active,

Yes, that could be a nice feature ...

> which could help to avoid
> accidentally selecting the wrong item (by scrolling a little more just
> as you clicked).

... though not as necessary here as with other input systems (mouse,
touchpad, etc.), since a "click" doesn't enter slide mode and thus
doesn't convey any movement information at all.

> (Though I suppose your approach with delays and thresholds would also
> prevent that.)

Yup. When the finger approaches the slider and when the pressure
changes, all this generates a lot of false movements, so I have to
do some aggressive filtering anyway. It just comes in handy in this
case :)

> So, which is better?
> I suspect it might come down to personal preference, actually...

I guess someone has to implement it, then we can compare :)

> Is it possible to update the screen fast enough to get a level of gray
> due to persistence of vision? (Think PWM on a per-pixel level.)

Hah, I hadn't thought of *that* ! :) My gut reaction was "no way
this could possibly work", but then I looked up the figures in
the data sheet, and it would seem that one could actually change
the display fairly rapidly.

The SPI interface can run at up to 10 MHz. We need to transfer
128 * 64 = 8 k data bits (*) plus some overhead. So that's
something like 2 ms per screen update. Less if only a small region
is changed.

(*) Hello marketing, just wanted to let you know that we have an
    8K display. Not just the crummy old 4K the industry is all
    excited about.

The OLED controller [1] seems to be able to go pretty fast: it has
a clock that can be adjusted from about 280 kHz to 540 kHz (figure
10-7 on page 43 - table 12-1 shows the tolerance at the default
370 kHz setting, not the full configurable range.)

The controller outputs one row at a time and - at the fastest
setting - needs 54 cycles for this. There are 64 rows. So that's
~100 Hz fps at the default setting and up to ~150 fps at top speed.

So yes, it seems that one could blink the display at some 50-75 Hz.


However ...

> I suspect it's not feasible in practice, though, even if it's possible.
> (Among other reasons, it would probably take too much power...)

... there is that, and we may even have a worse problem: while the
OLED controller generates a frame synchronization signal, this is
not brought out on the FPC of the module. As far as I can tell,
there is no way to synchronize CPU and OLED. So any such blinking
scheme would have to deal with the aliasing issues that would
result from this situation.

Thanks a lot ! Great food for thought !

- Werner

More information about the discussion mailing list