language-servers/slint
1
0
Fork 0
mirror of https://github.com/slint-ui/slint.git synced 2025-09-29 13:24:48 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

Simplify the debugging techniques topic for readability

Browse source
This commit is contained in:
Kavindra Palaraja 2023-08-18 18:29:20 +02:00 • committed by Simon Hausmann
parent 80407d0375
commit c55dda5ab8
1 changed files with 14 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/reference/src/advanced/debugging_techniques.md
View file

@ -1,27 +1,29 @@
<!-- Copyright © SixtyFPS GmbH <info@slint.dev> ; SPDX-License-Identifier: MIT --> <!-- Copyright © SixtyFPS GmbH <info@slint.dev> ; SPDX-License-Identifier: MIT -->
# Debugging Techniques # Debugging Techniques
On this page we're presenting different techniques and tools we've built into Slint that may help you track down different issues you may be running into, during the design and development. On this page we share different techniques and tools we've built into Slint that help you track down different issues you may be running into, during the design and development.
## Slow Motion Animations ## Slow Motion Animations
Animations in the user interface need to be carefully designed to have the correct duration and changes in element positioning or size need to follow a suitable curve. Animations in the user interface need to be carefully designed to have the correct duration and changes in element positioning or size need to follow an easing curve.
In order to inspect the animations in your application, you can can set the `SLINT_SLOW_ANIMATIONS` environment variable before running the program. The variable accepts an unsigned integer value that is interpreted as a factor to globally slow down the steps of all animations, without having to make any changes to the `.slint` markup and recompiling. For example `SLINT_SLOW_ANIMATIONS=4` will slow down animations by a factor of four. To inspect the animations in your application, set the `SLINT_SLOW_ANIMATIONS` environment variable before running the program. This variable accepts an unsigned integer value that is the factor by which to globally slow down the steps of all animations, automatically. This means that you don't have to make any manual changes to the `.slint` markup and recompile. For example,`SLINT_SLOW_ANIMATIONS=4` slows down animations by a factor of four.
## User Interface Scaling ## User Interface Scaling
The use of logical pixel lengths throughout `.slint` files allows Slint to dynamically compute the correct size of physical pixels, depending on the device-pixel ratio of the screen that is reported by the windowing system. If you want to get an impression of how the individual elements look like when rendered on a screen with a different device-pixel ratio, then you can set the `SLINT_SCALE_FACTOR` environment variable before running the program. The variable accepts a floating pointer number that is used to convert logical pixel lengths to physical pixel lengths by multiplication. For example `SLINT_SCALE_FACTOR=2` will render the user interface in a way where every logical pixel will have twice the width and height. The use of logical pixel lengths throughout `.slint` files lets Slint compute the number of physical pixels, dynamically, depending on the device-pixel ratio of the screen. To get an impression of how the individual elements look like when rendered on a screen with a different device-pixel ratio, set the `SLINT_SCALE_FACTOR` environment variable before running the program. This variable accepts a floating pointer number that is used to convert logical pixel lengths to physical pixel lengths. For example, `SLINT_SCALE_FACTOR=2` renders the user interface in a way where every logical pixel has twice the width and height.
_Note_: At the moment this overriding environment variable is only supported when using the OpenGL rendering backend. _Note_: Currently, only the FemtoVG and Skia renderers support this environment variable.
## Performance Debugging ## Debugging for Performance Improvements
Slint tries its best to use hardware-acceleration to ensure that rendering the user interface uses a minimal amount of CPU resources and animations appear smooth. However depending on the complexity of the user interface, the quality of the graphics drivers or the power of the graphics acceleration in your system, you may hit limits and experience a slow down. You can set the `SLINT_DEBUG_PERFORMANCE` environment variable running the program to inspect at what rate your application is rendering frames to the screen. The variable accepts a few comma-separated options that affect how the frame rate inspection is performed and reported: Slint attempts to use hardware-acceleration to ensure that rendering the user interface consumes a minimal amount of CPU resources while maintaining smooth animations. However, depending on the complexity of the user interface, quality of the graphics drivers, or the power of the GPU in your system, you may hit limits and experience slowness. To address this
issue, set the `SLINT_DEBUG_PERFORMANCE` environment variable before running the program, to inspect the frame rate. The following options affect the frame rate inspection and reporting:
- `refresh_lazy`: The frame rate is measured only when an actual frame is rendered, for example due to a running animation, user interface or some state change that results in a visual difference in the user interface. When nothing changes, the reported frame rate will be low. This can be useful to verify that no unnecessary repainting happens when there are no visual changes. For example a user interface that shows a text input field with a cursor that blinks once a second, the reported frames per second should be two. - `refresh_lazy`: The frame rate is measured only when an actual frame is rendered, for example due to a running animation, user interaction, or some other state change that results in a visual difference in the user interface. If
- `refresh_full_speed`: The user interface is continuously refreshed, even if nothing is changed. This will result in a higher load on the system, but can be useful to identify any bottlenecks that prevent you from achieving smooth animations. there is no change, a low frame rate is reported. Use this option to verify that no unnecessary repainting happens when there are no visual changes. For example, in a user interface that shows a text input field with a cursor that blinks once per second, the reported frame rate should be two.
- `console`: The measured frame per second rate is printed to stderr on the console. - `refresh_full_speed`: The user interface is continuously refreshed, even if nothing is changed. This continuous refresh results in a higher load on the system. Use this option to identify any bottlenecks that prevent you from achieving smooth animations.
- `overlay`: The measured frame per second rate is as an overlay text label on top of the user interface in each window. - `console`: The frame rate is printed to `stderr` on the console.
- `overlay`: The frame rate is as an overlay text label on top of the user interface in each window.
These options are combined. At least the method of frame rate measuring and one reporting method must be specified. For example `SLINT_DEBUG_PERFORMANCE=refresh_full_speed,overlay` will repeatedly re-render the entire user interface in each window and print the achieved frame rate in the top-left corner. `SLINT_DEBUG_PERFORMANCE=refresh_lazy,console,overlay` will measure the frame rate only when something in the user interface changes and the measured value will be printed to stderr as well as rendered as an overlay text label. Use these options in combination, separated by a comma. You must select a combination of one frame rate measurement method and a reporting method. For example, `SLINT_DEBUG_PERFORMANCE=refresh_full_speed,overlay` repeatedly re-renders the entire user interface in each window and prints the achieved frame rate in the top-left corner. In comparison, `SLINT_DEBUG_PERFORMANCE=refresh_lazy,console,overlay` measures the frame rate only when something in the user interface changes and the measured value is printed to `stderr` as well as rendered as an overlay text label.