🏠 back to Observable

Long Sparkline and Ring Buffer

I was experimenting with basics to understand how reactiveness works, and how to use viewof in some other thread here. And then sidetracked into moving sparkline from the HTML intro into its own notebook.

I wanted the width of sparkline to be dependent on amount of elements in passed array.

Then I got bored and made a sparkline that reacts to Observable now timestamp. This required a ringbuffer array to store previuos data. This is what I’ve got.

There are two bugs. Maybe it is only on Firefox though.

  1. When the buffer is reduced to zero, the number generator stops and never recovers again. (fixed thank to @mootari hint)
  2. If buffersize is reduced rapidly, then the sparkline still leaves some static flickering in the right part of the screen.

And the last thing I’d like to fix is the visible size of the defined controlled array, which doesn’t change after controlled.length is changed by slider.

The full notebook: Long Sparkline and Ring Buffer / Anatoli Babenia / Observable

EDIT: Non-recovering zero buffer is fixed.

1 Like

This line gives you NaN if len is 0:

buffer.offset %= len;

I frequently run into NaN “poisoning”, so I’ve made it a habit to drop in asserts during early development, e.g.

console.assert(!isNaN(buffer.offset), "offset is a number")

Cool notebook! I love ringbuffers! So fast

One of the coolest ring buffer tricks I read was using virtual memory to avoid the special casing of the wrap when bulk adding: The Magic Ring Buffer | The ryg blog Not that you can do that in JS but it’s interesting nevertheless.

1 Like

Thanks. Fixed. :smiley: In Python I would get an exception right away, and it is a surprise that JavaScript is so forgiving - it doesn’t turn the division by zero to error even in strict mode.

buffer.offset %= len;

And here is the catch. Once buffer.offset is Nan every operation with it gets Nan.

I actually forgot that % does division. :smiley: Blindly copied stuff from the StackOverflow page mentioned in the comment.

The hack to map one physical memory page into several memory virtual page, might be useful for passing the data if both writer and reader have the same speed. Otherwise there will be a problem if writer is fast enough to cross the physical page boundary twice before the reader finished reading the first page.

I think this can be visualized with two horizontal bars and arrow pointers moving around them. If writer would be painting with smooth gradient…

Can you record an example of that flicker? I can’t reproduce it in Chrome.

1 Like

I couldn’t find a way to attach .webm or animated .webp, so here is a .gif.


Curious. Which browser and OS? Can you reproduce it in other browsers?

Fedora 34, Firefox 91.0.1. I don’t use other browsers.

This looks like a graphics bug to me, and I doubt there’s much you can do within your notebook to fix it. On the bright side, other users are unlikely to encounter it.