-
I'm looking into creating custom GUIs on the reMarkable family of tablets. These tablets offer full root access via SSH, and there's a small but dedicated community developing software for the device. Notably, the devices have E-ink displays, and no GPU. Applications have to be developed with this in mind - they have to manually refresh the display whenever they update a portion of it, which can be done with many many different parameters (like waveforms and etc), all with different characteristics like latency and number of shades supported. The device also supports pressure- and tilt-sensitive wacom pen input. Onto the main course: I've used SixtyFPS in the past and it doesn't have enough features to be feasible for desktop app development. However it provides just enough features to look very attractive for embedded use on low-power touchscreen devices like the reMarkable. It seems like it'd be perfect for declarative UI design, layout and state management. But in order to do that I'd have to get it to keep pixels flowing & tend to the device's E-ink display properly. And accept input. First-party applications are developed using Qt and the proprietary eink plugin has been leaked in the past through the official SDK, but it's entirely possible that SixtyFPS's existing Qt backend will not be usable for this purpose. Therefore I'll most likely have to make my own custom backend. I already have CPU font & shape rendering support that provides high-quality results. What next? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
We currently don't have stable public API to do that. The only way to do it currently is to use the internal API, which we often break. Anyway, basically what one has to do is to re-implement the But a reMarkable backend would be great, and it might even make sense to have this in our repo, if you wish to contribute. |
Beta Was this translation helpful? Give feedback.
We currently don't have stable public API to do that.
The only way to do it currently is to use the internal API, which we often break.
You can see the source of 3 backends in https://github.com/sixtyfpsui/sixtyfps/tree/master/sixtyfps_runtime/rendering_backends
the
gl
andqt
backend are the one which are production ready. The MCU backend is work in progress, but is maybe what you might want to look into because it does the thing in software.We are still pondering about how to architecture that better since the MCU backend itself has "backend" for the different boards.
Anyway, basically what one has to do is to re-implement the
Backend
,ItemRenderer
andPlatformWindow
traits.Arguably, …