This week in SixtyFPS

22nd of November 2021 to 28th of November 2021 ‒ 0.1.5 Release

Posted on November 29, 2021

SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++, and JavaScript. Find more information at https://sixtyfps.io/ or go straight to github at https://github.com/sixtyfpsui/sixtyfps

Release of Version 0.1.5

We had a maintenance release. As expected for such a release: Your code should continue to work when you update from earlier 0.1 releases.

In addition to the SixtyFPS stand-alone viewer application, this release is the first to include Linux and Windows binaries for the LSP server and for the C++ package. You now longer need a rust toolchain installed to try out SixtyFPS from C++.

Get the SixtyFPS 0.1.5 release on github.

Changed

  • The sixtyfps compiler no longer "inlines" all the elements, resulting in faster compilation time and smaller binaries.

    See here for a more detailed explanation

  • Implemented basic constant propagation in the sixtyfps compiler.

Fixed

  • The Slider's changed callback was not being called with the fluent style (#621).
  • Fixed compilation error in C++'s sixtyfps::blocking_invoke_from_main_loop when the callable returns void (#623).
  • Improve rendering quality on High-DPI screens on Windows when using Qt.
  • Fixed linking errors when selecting the native style on Windows with C++.
  • Fixed the maximization button in the window decoration when a window has a fixed size.

Development Summary

MCU

We are trying to reduce the resource footprint and become even more efficient. As a benchmark, we are started on support for MCUs (microcontroller units): If a UI runs fluently there, then it will be no problem to run it anywhere else.

For the MCU work, we are moving towards making the core library of SixtyFPS build with #[no_std] (41e180, 80c060, 844c5c, 763065). To further reduce the weight of the library we started to trim disable features in the libraries SixtyFPS uses itself. (e.g. 5b4d6e)

An experiment was started to enable rendering on devices that do not have enough memory to save a full display buffer in 6a17ae and 20f41a.

C++ bindings

We want SixtyFPS to be useable from several programming languages. C++ is widely used, and we want to enable that ecosystem to benefit from the robustness of a rust UI library!

This week the C++ support was improved in preparation for the binary packages that were built for the 0.1.5 release!

Small bugs in the C++ layer were fixed in commits c15a59 and d96378.

SixtyFPS UI Library

Fixes

  • Fix warning about not existing image when using the interpreter ( 531dd9 )

    Can be reproduced by running the todo example with the fluent style and the GL backend

    The default image should be None, not an empty path

  • Fix a regression in layout due to non inlining (06d129)

    override_from_parent.60 was panicking when compiling rust because some expression had NamedReference that were relative to another sub component.

    Added a test as well for the case of multiple indirection (SubComp4) that was also broken

  • Fix regression when overriding the with of a Component that specifies limits (84e394)

    We were comparing the priorities of different component, which does not make sense

    This is a regression found with the crater run

  • Fix once more the description of @image-url in the tutorial (7a8890)

    PR #669 changed the wording, but the tutorial uses the sixtyfps! macro for which that wording was fine. Instead, be more explicit about where the file is looked up in both situation

  • Fix text rendered blurry when using Qt (fa14a8)

    After commit becb45 we'll make sure not to set the plugin application attribute when initializing the Qt backend. Unfortunately in the generated struct the NativeStyleMetrics field is placed and initialized before the m_window. The Default::default() impl calls ensure_initialized() with from_qt_backend = false because we don't know what backend is being used. Since due to the ordering this is the first call to ensure_initialized(), we'll end up setting the plugin application attribute.

    This patch fixes that by ensuring that the m_window field always comes first, which is initialized with a call into the run-time library, which in turn delegates to the backend. That'll be the Qt backend and we'll initialize the application object correctly.

  • Fix documentation of image file lookups (799dbf), contributed by @jrmoulton.

Janitor work

Fixes for issues found with cargo fuzz: 8b3084, and 37a2ad.

Statistics

52 patches were committed by 5 authors.