search

sargassum-world / latreutes

Desktop application for connecting to ZeroTier networks
Apache License 2.0
1 stars 1 forks source link

Make Latreutes run properly on low-power ARM64 CPUs #15

Closed ethanjli closed 3 years ago

ethanjli commented 3 years ago

Right now Latreutes takes significant CPU usage on ARM64 CPUs (used in e.g. the NVIDIA Jetson Nano), which is very undesirable. For example, idling on the home page causes 8 - 25% usage of a single CPU core, and idling on the Peers page causes 40 - 50% usage of a single CPU core - which is unacceptable. So React + Chakra UI is probably too heavyweight for these low-power CPUs. Should we consider Svelte + SvelteKit (perhaps with the Smelte UI framework or Sveltestrap?), or maybe even a native UI?

Even worse, when Chakra UI tries to perform animations (e.g. opening an accordion or a drawer), the frontend completely freezes. I was able to confirm this by adding the "reduceMotion" param to Chakra UI's Accordion component, which fixes the freezing behavior when opening accordions; unfortunately, the drawer component doesn't have a similar "reduceMotion" parameter.

ethanjli commented 3 years ago

On the feature/svelte-rewrite branch (PR forthcoming) where I've replaced React with Svelte, I'm able to run the built binary, and the CPU usage is much better - the Svelte rewrite of Latreutes uses almost no CPU. I suspect this is because my React implementation was not at all optimized and was redrawing everything all over the virtual DOM all the time; while in Svelte no special work was needed to achieve an extremely efficient implementation.

But so far - i.e. in https://github.com/sargassum-eco/latreutes/commit/42ff5a9554e8f3e6d9bd04ecf6f1e8988bfb81f1 - any time I do anything which causes a pure CSS transition/animation to try to run, e.g. opening the navigation menu at the mobile responsive breakpoint, the webview turns blank and freezes. This is the same behavior I observed in the implementation using React and Chakra UI. Fortunately, with Svelte I have direct control over animations; we may need to find a way to do a special build which disables all CSS transitions. It's not enough to just set the transition durations to 0, we actually have to remove the transitions themselves. This may require some rollup preprocessing for the scss files, as well as an environment variable and if-else guards for the Svelte code (which could become rather annoying to maintain).

The strange thing is that Svelte animations work just fine in the Svelte REPL in the browser (e.g. https://svelte.dev/repl/060336c5dbcb4eafa2d0a612a87d769c?version=3.12.1 ), and also certain Svelte transitions do seem to work under certain conditions (e.g. removing the transitions defined in CSS), such as the slide transition for the network accordions. I'll need to investigate which transitions do seem to work.

ethanjli commented 3 years ago

From troubleshooting, I found that the observed problem on the Jetson Nano (ARM64 architecture, running Ubuntu 18.04) with animations only occurs when CSS tries to do a transition on the transform property; this includes transitions hard-coded in my CSS files, as well as the ones generated by Svelte's animate directive in Svelte components. Setting a duration of 0 does not work as a workaround; instead, the offending Svelte directives must be deleted prior to svelte preprocessing (e.g. during rollup preprocessing, as in 29ba1fc53eb7788d022e2da2cac04f2d5060f2e1). I have no idea why this problem occurs only in Tauri and not Chromium on the Jetson Nano.

No other transitions seem to cause problems.