[Windows] Last two from v 2.xx family: Responsiveness issues

[qalisto]

Bug Report

IMPORTANT: Please follow this template strictly when reporting bugs. Providing detailed and accurate information helps the development team to understand and address the issue effectively.

App Version: [last 2 versions as of 2023-12-12]

Platform: [Windows 11 on Intel(R) N95 1.70 GHz Installed RAM 16.0 GB (15.8 GB usable)

Installation Method: [Direct Download / Other]

Bug Description: Loading and using 2.1xxx is so sluggish and unresponsive that I had to revert back to 1.x

Expected Behavior: normal, robust functionality

Actual Behavior: Expected app to not take 4-12 seconds to even enter a keystroke

Plus, memory usage was very excessive.

Am I alone here?

All other apps normal.

And I really like the changes I saw in the UI! :O :(

Is Bizarre.

[ransome1]

I haven't experienced any memory leaks myself nor haven't heard of any real performance issues. There was a rendering issue with very large todo file, but only during scrolling, plus it has been fixed in 2.0.3.

Without more details, I don't know what to do here. Maybe some Windows users can comment on it.

[amariusz]

It's not so extreme in my case but I've also noticed some delays. For example when I drag sleek-2.0.4-rc.1 window to another monitor (from normal window state to maximized on 1080p display, about 70 tasks in file) it takes about 5s to redraw it. No such issues with sleek-1.3.2-rc.1 or other app I'm using. I'm on latest Debian Trixie.

[ransome1]

@amariusz are you also experiencing any of the issues @qalisto is describing as well? Like a slow app start, an increased memory usage, 4 seconds to accept input from a keyboard and so forth?

[amariusz]

Not really, just redrawing while moving. It starts in about 3.5s, so OK. No real issues with memory consumption (340MB), no keyboard delay.

[andrei-a-papou]

No re-drawing issues on Debian 11.x either. The currently open file has around 50 todos. I'll monitor RAM usage and report if something is way off.

[ransome1]

This could be related to https://github.com/electron/electron/issues/29868#issuecomment-1472071904. The thread is about Windows Defender slowing down Electron based apps. I was skim reading the thread and nobody found a proper solution. However at the end somebody asks, if this might be related to missing code signing. And if because of that Windows Defender might be slowing the app down.

So I checked the building pipeline of sleek and saw, that for the last releases, the code signing for the Windows builds did not happen. Was Windows asking you guys something like "if you really want to open the app", or similar?

After fixing the pipeline, the Windows builds are now properly signed again. It's a long shot, but please feel free to give it a try @qalisto @amariusz @andrei-a-papou @swantzter: https://github.com/ransome1/sleek/releases/tag/v2.0.4-rc.3

[swantzter]

@ransome1 well 2.0.4-rc.3 and above is signed with a certificate. But I still get a warning when trying to install the application that it comes from an unrecognised/unverified publisher.

I looked at the installer properties and (pardon me, non-work laptop is in swedish) I get a list of signatures, as expected:

Upon digging into it via "Information" I'm told that it is signed but that the certificate in the signature cannot be verified. Looking further at the signature chain it seems the executable ahs been signed by an Apple Developer certificate which is not a valid/trusted windows code signing certificate

I get this error message when trying to install, it's bypassable via "More info"

[ransome1]

I think I was mixing things up:

• We are able to use the Apple Developer certificate to push sleek to the MAS and also sign the binaries.
• We are able to use the Microsoft Developer certificate to push sleek to the Windows App Store but are not able to sign the binaries with it.

The pipeline trying to use the Apple certificate to sign the Windows app, was me not giving it enough attention. I removed the signing process from the Windows pipeline.

So I guess sleek's Windows binaries were never signed in the past, unless it was downloaded via the Windows App Store.

I'm refactoring a lot currently and will push an experimental pre-release of 2.4 soon. Since qalisto has gone rogue, can I ask you to check if it runs more smoothly now (on Windows)?

[ransome1]

@swantzter could you try out rc.5 on Windows and let me know, how it runs? https://github.com/ransome1/sleek/releases/tag/v2.0.4-rc.5

[qalisto]

Hello, I got around to first (today) trying 2.04 rc5 and it proved to be far more robust. Then, in last few hours, rc.6 came and I will now test it.

Whatever was making the problems 3 weeks ago are addressed, although, the interesting UI improvements clearly came at a cost to my sys setup.

Was it expected that, for example, New ToDos would be slower to activate and tab navigation would be several milliseconds slower compared to 1.x?

In any case, 2.04 rc.6 clearly no longer presents the "molasses" issues before.

Need to get used to the new UI changes. I do miss the "Clear" function that was used to exist at bottom of Calendar icon when setting Date. I found it indispensable for eliminating Due Dates when the key parameter for the Task became Project Dependent vs Time Dependent.

Am relieved because I am intriged by the improvements. ###

[andrei-a-papou]

Was it expected that, for example, New ToDos would be slower to activate and tab navigation would be several milliseconds slower compared to 1.x?

I second that. While v2.x has lots of UI and UX improvements, the new animations do take more time to execute, so it does feel somewhat less snappy than 1.x.

[ransome1]

If it is just the animations, which make it feel less snappy to some users, and not the general performance, this could be easily solved by a setting. Since we're using React, almost all animations can be disabled by a single line of code. I could add this setting in the next release, but it would be a hidden one. You would need to change it in the config.json.

[andrei-a-papou]

@ransome1 Under Linux, yes, it feels like just the animations, not a general kind of sluggishness. I'm using a pretty old laptop, by the way. I'd love to test this hidden setting when it's available.

[ransome1]

@andrei-a-papou @qalisto the new setting is part of: https://github.com/ransome1/sleek/releases/tag/v2.0.4

I did not add it as a toggle in the settings window. Instead you will have to manually edit the config.json. To locate it please check this page: https://github.com/ransome1/sleek/wiki/User-data-folder-location

There is also a built in way of using the window menu's sleek entry, then About and then Reveal location of config folder.

The settings name is disableAnimations and it is set to false per default. Change it to true, save the config and restart sleek. I tested it, but if it doesn't work on your side, please let me know.

[andrei-a-papou]

@ransome1 Thank you, it seems to be working fine! I'll keep animations disabled for now and report any issues.

[andrei-a-papou]

@ransome1 When I toggle the navigation (e.g. via Ctrl + Alt + H), animations appear to be only partially disabled, which looks a little weird. Would it be possible to fully disable them for toggling the navigation?

[ransome1]

That should not be a problem. I will add this to the next release.

[ransome1]

@amariusz I was able to remove some MUI (the framework, that helps me building the GUI) overhead from sleek. And looking at the performance metrics in the developer tools, it did improve for instance the startup time a little bit on my machine. But I never really had issues on that hardware, so it's hard to say, if these improvements have an impact on different, maybe older hardware, or not. But it is worth a shot I think: https://github.com/ransome1/sleek/releases/tag/v2.0.7-rc.1

[amariusz]

Unfortunately I haven't observed any performance improvments with this version. Startup time is OK for me (3s), but as I've wrote before - maximizing Sleek's window can take up to 5s. Resizing the drawer is not very snappy, the animation lags behind mouse curosor a bit. But that's not an issue for me.

BTW. If I resize the drawer up to the point when terminal output is showing some negative value:

Set drawerWidth to -11

.. and release the left mouse button - it becomes impossible to change drawer width. It seems the only way to get this behaviour back is to fix it manually in config file by setting e.g. "drawerWidth": 100.

[ransome1]

Resizing the drawer is not very snappy, the animation lags behind mouse cursor a bit. But that's not an issue for me.

Have you tried deactivating animations? There is now a setting in the interface. You might need to restart the application.

BTW. If I resize the drawer up to the point when terminal output is showing some negative value:

This is interesting. How do you achieve this? On my end I cannot drag the drawer this far to the left.

[amariusz]

Have you tried deactivating animations? There is now a setting in the interface. You might need to restart the application.

Yes, I have tried. Some animations are evidently gone but performance wise I'm not observing any significant difference.

This is interesting. How do you achieve this? On my end I cannot drag the drawer this far to the left.

While dragging the edge and shrinking the drawe UI resizes up to about 300 pixels(?). After this point resizing stops, but I if I continue dragging terminal reports lower values and then negative ones.

[ransome1]

While dragging the edge and shrinking the drawe UI resizes up to about 300 pixels(?). After this point resizing stops, but I if I continue dragging terminal reports lower values and then negative ones.

Well observed. I can reproduce it.

[ransome1]

but as I've wrote before - maximizing Sleek's window can take up to 5s.

@amariusz about the window operations, could you please check https://github.com/ransome1/sleek/releases/tag/v2.0.7-rc.2? In the previous versions operations like resizing or changing the position of the window were persisted while the event was firing. This did not seem to be an issue on Macs. But I read, that Windows systems tend to fire the events more frequently. And of course if resizing the window fires hundreds of events to persist the new dimensions, this could lead to a laggy resize process. v2.0.7-rc.2 has now a delay implemented, which persists the settings only once per event and only 500ms after it has finished.

Generally this should be good practice but I cannot say for sure if this solves the issue on your end. It will definitely not solve the lack of snappiness in your drawer through. It is worth a try.

[amariusz]

That seems to be the rootcause - with v2.0.7-rc.2 maximizing and resizing is instant on my Linux (Debian Trixie, KDE)! 👏

[ransome1]

It's good to hear that it improves the issue on Linux! If you ever come across a Windows machine, please let me know, if it has the same positive effects.

[qalisto]

(1) Did clean install of 2.0.5 (2) Disabled Animations

But, CPU consumption jumps from avg of ~0.2 - 6.0% and RAM jumps with v 2.x from 161mb to 264mb on same ToDo file.

So for me ... more optimizations are hoped for.

Rolling back to 1.3.2. It's snappiness still eclipses the UI improvements of 2.x.

Again, let me note that the UI changes are very nice, but too taxing on my particular Box.

If there are any Security reasons to stop using 1.3.2 (and I should go to 2.x), please kindly advise.

If you think significant optimizations may have been made and I should give latest pre-releases a shot, please also advise.

Sorry for time lags, I can see I will be overclocked for this quarter at least.

[ransome1]

(1) Did clean install of 2.0.5 (2) Disabled Animations

The option to disable animation has only been introduced with 2.0.6. I assume you mean 2.0.6 right?

But, CPU consumption jumps from avg of ~0.2 - 6.0% and RAM jumps with v 2.x from 161mb to 264mb on same ToDo file.

To me that sounds like what an Electron apps consumes. For instance, just firing up Notable (my Electron based note taking app) consumes > 220Mb without me having done anything with it. Or take MS Teams, I see a RAM consumption of almost 1Gb just having it open and chatting. But than again, it's known to be a terrible app.

This is what sleek's 2.0.6 RAM consumption looks like on my system (Of course we cannot compare my Mac based environment with yours, but I would assume that the Ram consumption is generally comparable). Two files open, sleek is in foreground but idle:

Same setup with 1.3.1

On the CPU side however I see a slightly higher consumption on 2.x during usage such as opening the dialog or drawer.

This is what 1.3.x looks like performing the same tasks

So for me ... more optimizations are hoped for.

Honestly, I wouldn't count on it. 2.x comes with a more resource hungry framework and it is very unlikely we're going to remove it as the benefits outweigh potential performance issues on certain hardware. If some React/MUI expert gets on board there might be some more performance enhancements coming up, but I don't think this will please your requirements.

If you're happy with 1.3.x you could simply stick with it. But since it is not being updated anymore, I would advice you to built it from source code and before doing this, to update sleeks dependencies. Because those are outdated and may pose a security risk.

I triggered one last build based off the 1.3.x branch: https://github.com/ransome1/sleek/releases/tag/v1.3.2-rc.2

If you simply keep rebuilding it from time to time, you should be fine.

[qalisto]

thanks for info:

▒▓▒>>> You Said: "If you're happy with 1.3.x you could simply stick with it. But since it is not being updated anymore, I would advice you to built it from source code and before doing this, to update sleeks dependencies. Because those are outdated and may pose a security risk.

▓▒▓>>> I Comment:

(1) sorry, I am not a Coder. Is building from the availed source code do-able by a tool within GITHUB? Or do I need to go to Microsoft and get compiling tools for my OS/Processor config?

(2) Is there a webpage that lists the current Dependencies for the extant versions of Sleek?

[ransome1]

@qalisto you don't need any coding knowledge to build the app from source.

The minimum you need is to install node.js.

Next you would download the source code. You can either do this with the Git command line tools using a shell. In Windows you have PowerShell for this.

But you don't need to do this, you can also simply download the source code from GitHub:

Once you have the sleeks source code on your computer, you need to extract it and navigate into it using a shell.

Once in sleek's directory, you simply need to type:

1. npm install
2. npm run build:windows

This will build the app and the result will be placed in the /release/build/.

[qalisto]

@qalisto you don't need any coding knowledge to build the app from source.

This will build the app and the result will be placed in the /release/build/.

@ransome1: Clearly stated and understood. Thank you sir!

[aubreyz]

I'm trying to get back to sleek after a long break using other todo.txt software. I imported my todo.txt file (about 2500 entries) and I ended up getting to this issue/thread to see if others were seeing what I am seeing. I am getting EXTREMELY sluggish performance on Windows. For example, to scroll through the 2500 unfiltered entries (which takes about 3 seconds in a text editor) took over 4 minutes. Rendering each single page of scroll took a huge amount of time. Working on a filtered subset makes things a bit faster - but not much (filtering down to about 200 entries still takes many seconds - like about 10 seconds - to view the next batch of about 20 items). Sleek is looking great, but this problem makes it unusable for me as an alternative right now.
I don't think this is going to be a Windows defender issue as I have that turned off.