Bad apple (video) playing on a pinetime

[TT-392]

The way you write something to the display is: x1, y1, x2, y2, bitmap. I call these blocks.
Basically, writing a new block takes time, and writing pixels in a bitmap takes less time, so the bigger the blocks the better. So basically, if you have a block of 10x10 of changing pixels, with one non changing pixel in the middle, it is faster to overwrite that pixel, than to write 4 blocks around it. So that is basically what the preprocessor does. These blocks are then put in a file, with coordinates of the blocks (second relative can be encoded in 4 bits), followed by a 1 bit bitmap.

Is it that both the 'disk' (flash) is limited _and_ the write speed to the display?

Both the flash and the display share the same 8 MHz spi bus. This spi speed, and the fact that the only real way to send data to the display is in bitmaps (as in, you can't just tell it to draw a line or square, you have to send each pixel individually), in practice, this means that the fastest way to rewrite the entire screen is 125 ms (8 fps). We aren't really limited in terms of flash speed, because there is enough still frames, and frames where not much happens that enough data can be fetched to keep the buffer full.

barray

---

Given the nature of the video, it could be worth checking out some vector graphics. The decision of what to send next to the display could possibly even be done real time.

I don't really see how this would speed things up or would make things more compact, also, you could probably do the processing real time, but stuff would be a lot less optimized.

barray

This file is then lz4 compressed, and written to the spi flash of the pinetime. The pinetime decompresses, processes the blocks, and writes them to the display.

That sounds awesome  Do you get much savings with lz4? I assume the data you are sending is already pretty high entropy?

It goes from 5046208 bytes to 4099181. Which makes it small enough to fit in the 4 MiB of spi flash

As for bluetooth streaming, I kinda doubt that would be doable, I haven't looked into bluetooth yet, but if the speed is anything like the time it takes to upload through nrf connect (uploading this video takes about half an hour). I doubt that is gonna happen. But idk, maybe some optimizations are possible.

Depends how much data you are sending, but BT should be capable of some reasonable bitrate if you can stream audio over it. You'll definitely want some buffering though (as you do with audio).

The benefit to such a system is that you could potentially then stream all kinds of things from say a computer or mobile - it could lead to very interesting capabilities. For example:

* Remote photo taking on a camera
* Stream map data from phone
* Play a high-end graphics game streamed from your phone to watch (and use the watch as a dumb terminal of sorts) - games that could be cool are fruit ninja or angry birds for example

Anyway, if video could be streamed via BT it could add massive functionality!

Full color imagery, where small changes in color tint happen all over the display quite often (like remote photo taking on camera) is gonna be really slow on this display, this video is really only possible because big blobs of the same color pixels are moving around the display, though, still images of the camera, or, if a max speed of 8 fps, are probably possible (depending on bluetooth speed and stuff of course). For this same reason, games streamed from your phone are gonna look horrible, if they aren't specifically optimized for this display. Also, bluetooth as a protocol is definitely capable of high bitrates, but idk about this specific implementation of low power bluetooth hardware, I'd have to look into that.