Lagging when opening emoji-test.txt

The issue

When I click on the note that is created based on emoji-test-txt, regardless of being in wich layout of the Code View or even in the experimental WYSIWYG editor, Joplin laggs and stop functioning. The only way out I found is to click on another not and wait until Joplin understands that it should switch to another note.

How to reproduce

  1. Download the emoji-test-txt from unicode.org
  2. Copy the content of the emoji-test.tx to a new note in Joplin

Expected behavior

Don’t lag or at least don’t lag that much.

Observed behavior

Joplin become unresponsive.


Joplin version (AppImage):

Joplin 1.0.216 (prod, linux)

Client ID: 2f9120d318dd49e7889b65150fa0fbeb
Sync Version: 1
Profile Version: 29

Revision: 4eb680d (master)

OS version and type:

Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

@s4rc1na

Hi,

I thought I would try emoji-test.txt to see if I could duplicate what you are experiencing.

On Windows 10 x64 there was a very brief pause as the note rendered then it was easy to scroll and use afterwards. There was also a brief pause when I clicked on another note before Joplin rendered the new note.

On Linux Mint 19.3 x64 was a also very brief pause as the note rendered then it was easy to scroll and use afterwards. There was also a brief pause when I clicked on another note before Joplin rendered the new note.

The Win10 machine has an old Phenom II X6 processor and 16GB RAM. The Linux machine has an Intel Celeron N3350 and 4GB RAM. Both are running Joplin 1.0.216.

Basically, I could not reproduce your problem. Joplin had to think a bit when opening and closing the note but did not lag excessively or stop functioning.

Linux Mint is Ubuntu-based (which your machine is running) so could it be that your machine is of a lower spec or was busy doing other stuff at the time?

As an aside, what I did notice was different renderings between the devices / views.

Linux - Markdown Editor


Mono emojis - Skin tone is a separate "patch" beside the emoji.

Linux - Markdown Viewer


Mono emojis - Skin tone is a separate "patch" beside the emoji.

lin_viewer

Windows - Markdown Editor


Colour emojis - Skin tone is a separate "patch" beside the emoji.

Windows - Markdown Viewer


Colour emojis - Skin tone is applied to the emoji.

win_viewer

Just an observation.

I am not really an emoji user :grinning: :+1: :pizza: :volcano: :soccer: :warning: :antarctica: so I do not know if any of the above is to be expected.

I don’t think hardware by any chance is the issue:

How did you install Joplin on your Linux Mint? did you use AppImage file?

I suppose you might just have enough power in your computer to get by!!!

Yes it was the AppImage and I also now use the script to update it (not that that should make any difference). So my systems are much less powerful than yours yet I do not get any issues…

Mint’s DE is Cinnamon. I don’t suppose your DE (or display server) could have any impact on what you are seeing do you? No great Linux knowledge here, just making random, wild guesses!!

I wonder how much time did the brief pause on your machines took. Thanks to your comment it occurred to me to check the duration of the lag and if the lag CPU related or IO related. It turned out that on my machine it is CPU related (I waited for some time to have some baseline or the current CPU and diskIO and then switched note to the emoji-test:

As can be roughly estimated from the CPU usage plot, the rendering duration for the code view markdown text (until I can do any scrolling and see responsiveness from Joplin) is about 20 seconds and the single-thread CPU usage can go close to 100% but generally staying around 70%.

Regarding your speculation on Desktop Environment and/or window manager, I personally doubt it has major effect as the window is maximized at all time and nothing is changing other than the mouse pointer moving over joplin notes and then clicking. Also htop indicates that Joplin-related processes are having those "high" CPU usages and not any other process. At the time of writing this and taking the screenshot above, I have:

  • one instance of Joplin
  • one instance of Spotify
  • one instance of Alacritty
  • one instance of qpdfview
  • one instance of Dolphin
  • one instance of Slack
  • one instance of Seafile client
  • one instance of Flameshot
  • one instance of Vivaldi with 17 tabs
  • 8 instances of Firefox with a total of 50 tabs

so my DE is in fact not that free :sweat_smile:, and in total 363 processes (ps aux | wc -l), and yet Joplin manages to standout in CPU usage while opening this unicode test file.

To be clear, I'm not pitching this as a bug report as I understand that unicode test file is massive compared the notes usually written in such note taking app. This was an observation I had and I thought it might worth reporting. :slight_smile:

It was just long enough to see the text in the render pane without any syle applied (i.e. a brief view of

# emoji-test.txt
# Date: 2016-11-16, 18:29:53 GMT
# © 2016 Unicode®, Inc.

as H1 text but Times New Roman).

Then the styles were applied and all was well. By “brief” I am talking less than a second but noticable compared to “normal” notes (or rather ‘it was noticable unlike “normal” notes.’)