Releases: owulveryck/goMarkableStream
v0.11.1
There was an issue with the previous release; this is the release to use for FW 3.6
v0.11.0
This version has some breaking changes and will only work with FW 3.6.
- The CPU usage remains low, but is a bit more important: a bit more than 12% on nominal usage
- the network consumption on almost blank pages is very low with the change of implementation of the RLE (I cannot use uint4 anymore), but is a little bit higher on complex pages (but it remains more than acceptable).
v0.11.0-alpha: small hack for FW 3.6
This is an alpha release supporting firmware 3.6.
This release is not bullet proof.
- It consumes a lot of CPU due to the gzip compression
- there is no colors (and even worse, the blue is not rendered at all).
Use it only if:
- you want to contribute or
- you really need to present something remotely :D or
- you are an adventurer
v0.10.0
The stream listens to events from the pen or the touch.
It sends the picture for 2s after the last event.
The consequence is that the process consumes nearly 0% CPU even when the stream is opened.
v0.9.0
This is another implementation using a stream of data instead of the websocket.
This release includes several optimizations, and for one picture every 200ms, the CPU usage should be less than 10% (and remains close to zero when idle).
You can change the framerate with RK_RATE parameter, and with 100ms you got near realtime but with a little bit more of CPU.
v0.8.8
The streaming is stopped after 1 hour.
It means that there is a need to refresh the page after one hour, whatever the activity is.
v0.8.7
- Under the hood, a
sync.pool
has been implemented to lower the pressure on the GC which improves the performances (25% CPU in normal utilization) - add new configuration variable:
RK_RATE Integer 200
200 is the pause time between two pictures. You can lower it to reach near realtime, but the less you add, the more CPU intensive it is, and therefore it drains the battery faster.
v0.8.6
v0.8.5
v0.8.4
- Added functionality to handle excessive requests and preserve tablet battery life. Implemented a lock mechanism to regulate the number of simultaneous requests and prevent overloading the tablet.
- Included various wait screens to provide a better user experience during periods of high traffic or when the lock is active.
- Introduced a timeout feature to mitigate potential memory leaks caused by unclosed tabs.
Note that there are known issues with Safari, and efforts are being made to address and resolve these problems in future updates.