[ogoffart]

Hello HN! SixtyFPS founders here. We're two engineers who started this project ~6 months ago because we love good APIs and good toolkits that boost overall productivity. We'll be around here to answer questions. At this point, the product is still in a very early alpha stage, but we are eagerly looking forward to your feedback on technical features as well as on a scalable business model.

Our short term goal is to get involved in a paid project that would require a GUI frontend and where we could make use of this project. If you have any recommendations, or if you know of any such project, we would be happy to hear from you.

[ddeck]

Congratulations on the project!

The description mentions targeting embedded applications. What's the definition of embedded in this context? I see "several hundred kilobytes of RAM" mentioned - What's a minimal configuration likely to look like?

Just trying to get a feel for the typical embedded application that you'd be targetting. Most of the embedded work I do is with <= 64kb RAM, which I'm guessing is not your target.

It might be helpful if you could perhaps contrast the product with existing (similar?) libraries such as as LVGL[1], uGFX[2] etc.

[1] https://github.com/lvgl/lvgl

[2] https://ugfx.io/

[tronical]

Hi ddeck!

We need to make our description a bit more precise - and we're working on comparisons. In terms of pure RAM usage (as opposed to ROM) in our experience the display resolution contributes a lot to what's left (unless there are dedicated frame buffers). So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?

Generally I think we're aiming a little above LVGL/uGFX in terms of configuration, but also with with a much richer UI / features.

[ddeck]

>So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?

Typically displays with integrated SRAM. To give an example, a recent project used a 480x320x16-bit display and an MCU with 64kb SRAM. The display/drawing buffer took 38kb of that (i.e. 1/8 of the display).

[tronical]

Cool! I’d say that’s the very low end for us, but we think that it should be possible to create decent UIs also for such configurations. It would require additional work for us to target that right now but we’d be happy to take that offline. Drop us an email at [e-mail] please if you’re interested:)

[beojan]

How does this relate to Qt? I see that both founders worked for Trolltech and your other reply says SixtyFPS uses Qt styles on desktop (all Qt styles or just the ones shipped with Qt?) so clearly there's a close connection there. Does it build on top of Qt or is it a replacement, and if it is a replacement is it source / binary compatible?

[tronical]

The software is not built on Qt. The compiler and runtime is written in Rust (Qt is C++), the renderer is a lightweight GLES 2.0 renderer and winit is used for window creation and events.

The runtime’s API is available as plain C++ API (only depends on C++ standard library), JS api in node (via neon) and Rust natively (simply a crate). It’s generally rather lightweight in terms of its surface. Instead the focus is on our compiler generating API for the input design files, to make it easy to manipulate properties or feed data models into the UI.

We’re internally using QStyle calls to produce images of controls when selecting that kind of styling at compile time, but that’s entirely encapsulated. The style you see in the wasm demos for example is entirely done using GLES accelerated primitives (such as SDF based anti-aliases rectangles).