SixtyFPS UI Library
De-Inlining Status Update
The de-inlining work has been integrated this week and the compiler will now produce de-inlined code by default with commit 61202c.
The environment variable
SIXTYFPS_INLINING can be used to still force inlining in the compiler.
Here are some results of compiling the SixtyFPS Printer demo
|C++ generated header size||C++ binary size||Compilation time|
|Before (all inlined)||1.4M||2.3M||40 seconds|
|Now (de-inlined)||852K||1.4M||21 seconds|
|Rust generated code size||Rust binary size||Compilation time|
|Before (all inlined)||2.9M||6.9M||85 seconds|
|Now (de-inlined)||1.9M||6.4M||67 seconds|
These numbers are all for a release build. The Compilation time is measured by the incremental time of just changing the .60 file.
The C++ binary is dynamically linked to the SixtyFPS library and reads its resources from disk. The rust binary on the other hand is statically linked to the SixtyFPS library and has its image resources baked into the binary. So the binary sizes are not directly comparable between the two languages.
- Fix the maximization button in the window decoration when a window has a fixed size (PR #642, thanks @Aursen)
Improvements and Refactorings
- Move more of the winit related code from PlatformWindow impl into WinitWindow (51469b)
This will allow code sharing with the simulator in the future.
- Make the GL backends' winit driven event loop a reusable module (3c0607)
Abstract away the dependency to the former GraphicsWindow by
(1) Renaming GraphicsWindow to GLWindow (2) Introducing a WinitWindow trait
- Const propagation (a3adfd)
Inline access to constant properties
- Start doing some constant evaluation (de43f0)
There was a warning in the C++ generated code in the tests: (in test_cpp_image_geometry)
/tmp/AMWqZ.cpp:307:85: error: self-comparison always evaluates to true [-Werror,-Wtautological-compare] this->image_in_layout_fit_ok.set((sixtyfps::cbindgen_private::ImageFit::contain == sixtyfps::cbindgen_private::ImageFit::contain)); ^
Doing some simple evaluation prevent this warning at least
- handle tab key-code in backend (PR #639, thanks @phi-gamma)
Treating the Tab key as text disallows handling Shift-Tab because the shift modifier will not be passed down. This makes the handling of Tab analogous to Escape, Return and other non-text key-codes.
46 patches were committed by 4 authors.