# Misc Notes

> [TOC]

## C++ Version

We are seriously considering a c++ version of the app that still keeps the core logic in nim, this would imply moving the core logic to a nim library (status-lib), ensure the base app is as simple as possible and then migrate that base app to c++. Some experiments on this include Richard's [status-cpp](https://github.com/richard-ramos/status-cpp) and the [sandbox app](https://github.com/status-im/StatusQ/tree/master/sandbox) on statusQ
Some conclusions/thoughts include:
- There is no visible performance or memory usage improvements with a c++ version as both status-cpp and status-desktop have comparable memory & cpu usage using the same QML frontend. This seems to indicate that the QML code should be the first main the focus of any performance / memory improvements to do and it's not something wrong with Nim.
- It's easy (and arguably much easier than with a nim version) to compile to multiple platforms and devices using a "vanilla" QT c++ version of the app as Qt already provides all that functionality out of the box.
- We need to refactor some code to ensure the view / base app has as little logic as possible as this would make it much easier to migrate
- We also need to check on how to use a Nim library in C and understand any implications this might have

## Audio Messages Feature

~~We have a [branch](https://github.com/status-im/status-desktop/tree/feat/audiorecorder) for this feature but we're currently stuck. We need to explore using [opus codec](https://opus-codec.org/docs/).~~ PR done, awaiting designs.

## Upgrade Qt 6
We have updated to Qt 5.15 in this [PR](https://github.com/status-im/status-desktop/pull/2712). However Qt 6 requires quite a few changes to [DOtherside](https://github.com/status-im/dotherside), and if we move to a c++ version it isn't worth it, so we're holding off for now.

## Status Node Management
This is currently being researched, the goal is to be able to support in Desktop configuring how much a user wants his node to participate in the network. Waku v1 can have the bloom filter configured, waku v2 can support enabling or disabling relay mode, but also a) store and provide historical messages to other nodes, b) provide filtered messages to filter nodes, the subset of peers it sends messages to is also tweakable.

## Plugins

We did some experiments with html/js plugins that look promising, we were able for e.g to do a message apps (e.g [tic tac toe](https://github.com/status-im/status-desktop/blob/plugins_test/ui/app/AppLayouts/Chat/ChatColumn/MessageComponents/test2.html#L1)) that are fairly easy to develop. This is in the backburner for now however as we are focused first on communities & other features. A Discuss post elaborating this and other finds is in the wors.

## Syncing

Better/improved syncing is something being worked by the status-go team currently.

## Scaling Issues, Zooming

We are aware of scaling issues in some cases ([#2098](https://github.com/status-im/status-desktop/issues/2098), [#2178](https://github.com/status-im/status-desktop/issues/2178), [PR#2429](https://github.com/status-im/status-desktop/pull/2429)). This is currently being addressed first from the ground up with the work on StatusQ.

## status-im:// links

The main issue with this is that we need to update the registry on windows, make calls as root on linux, etc.. and we realized an installer is needed for this and we're currently working on one.
[#837](https://github.com/status-im/status-desktop/issues/837), [PR#965](https://github.com/status-im/status-desktop/pull/965)

## Building on M1 Apple Processors

Status Desktop doesn't currently compile on M1 Macs since it's a different architecture etc.. We are aware but it's currently in the backburner / not high priority

## Logout

Currently the Logout feature will exit the app, this was done since reseting the internal state turned out to not be so trivial. At some point we will revisit this so the logout doesn't need to exit.

## Communities

Phase 1 & 2a done. [Communities Progress](/CjQb5wtxT8SDSeV5BxNPRQ)

## Dropped Messages in Group Chats (in windows in particular)

There is this issue in which Group Messages often don't appear to everyone, after discussion with Andrea, this seems to be likely because in a group chat each message is encrypted for each group member, since in windows the encryption is quite slow by the time some messages are sent they have already timeout. Possible fixes to this include making changes in status-go, use a different encryption library in windows, increase the timeout.

## Flickering when using multiple monitors

In some rare cases when the app starts in an external monitor, it can have this flickering effect. We discovered this is an issue with Qt itself, and can sometimes be seen in other Qt apps as well. Dragging the app between monitors typically solves the issue. We're hoping that Qt 6 fixes this issue.

## CPU Usage

Looking at activity monitor isn't very reliable sometimes as it can fluctuate a lot, the best is to look at the usage over a period of time, for that we created a script to measure this (can be found here https://gist.github.com/iurimatias/ae0896e3d54fd635d4baa773fc206d44 , very hacky but it works).

we previously found a [commit](https://github.com/status-im/status-desktop/commit/dc9de1968fb6924fedd962f8ec47371a7b8dbfa0) that introduced a CPU usage issue
**Before that commit**: average cpu usage: 2% minimum 0.6%
**After that commit**: average cpu usage: 12% minimum 6.8%
***now* with the fix on master/PR#3081**: average cpu usage: 1.5% minimum 0%

It's a definitive improvement. However It's also important to also understand the different situations (as the words 'idle' sometimes mean different things to different people depending on the context)

* Background - app is completely in the background not selected
* Foreground idle - app is in the foreground but the user is not doing anything at all
* Foreground active - app is in the foreground and user is actively using it

**Background**

here we're getting according to last I measured

{ cpu_per: 0.8899999999999989,
mem_per: 2.300000000000005,
vsz: 6190531.633333334,
rss: 394075.1666666667,
cpu_min: 0,
cpu_max: 10.1

**Foreground Idle**

So the app is in the foreground but the user is not doing anything, so it's "idle"

{ cpu_per: 1.4983333333333326,
mem_per: 2.300000000000005,
vsz: 6190509.7,
rss: 393817.8333333333,
cpu_min: 0.6,
cpu_max: 18.1 }

**Foreground active**

Here I got these results, which are actually pretty good

{ cpu_per: 5.599166666666667,
  mem_per: 2.400000000000001,
  vsz: 6217631.5,
  rss: 407376.93333333335,
  cpu_min: 0.7,
  cpu_max: 15.6 }

When an app is in use, it *will* use a lot more CPU, **this happens with other apps as well so it is to be expected**

for example discord:
<video width="740" height="480" src="https://user-images.githubusercontent.com/176720/127223276-fbe84a79-de49-4219-abd7-63fd36833fc3.mov" type="video/mp4" controls /><br>

discord is electron so it kinda sucks, but even Telegram that is in C++/Qt has high cpu usage with normal usage:
<video width="740" height="480" src="https://user-images.githubusercontent.com/176720/127223388-028c3518-833e-4cb8-9dcb-deca34f0aa7e.mov" type="video/mp4" controls /><br>

in our case I got this:
<video width="740" height="480" src="https://user-images.githubusercontent.com/176720/127223423-3e73b2ca-39c2-42b0-87ef-a59137a9d641.mov" type="video/mp4" controls /><br>