Todos only partially shown while scrolling

[callegar]

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: 2.0.2

Platform: Linux

Installation Method: Direct Download, AppImage

Bug Description:
Using sleek 1.3.1 I have progressively created an archive of completed tasks todo_done.txt that is largish (538 entries, one line each). When I open this with sleek 1.3.1 everything shows regularly. When I open it in sleek 2.0.2, only a small fraction of these tasks is shown. Interestingly enough, the search field when empty says "Visible todos: 538" (the right number), even if for sure only about a hundred are shown. Searching for an unshown todo also makes it appear.

Steps to Reproduce:

1. Open a large archive todo_done.txt
2. Count the shown tasks in the sleek window
3. Realize they are way less than the tasks in the file
4. CTRL-F shows the actual number of entries in the file

Expected Behavior:
One should be able to scroll through all the completed tasks

Actual Behavior:
One can scroll through only a fraction of them, then the scroll stops. By configuring sleek 2 to show the entries in the order they appear in the file, you see that it stops after about 100 entries (actually 110).

Additional Information:

• [Include any additional information that might be relevant to the bug, such as error messages or console logs.]

Screenshots:
[If applicable, include screenshots that demonstrate the bug.]

[mshuflin]

This is also happening with my todo.txt file (with about 400 todos), not just my done.txt file

[callegar]

I have started using sleek with my second machine, which is an older i7 (haswell). This hardware is certainly not fast by todays' standard, but is still perfectly usable (16GB, SSD, etc) and better than some newer low end machines.

On this machine, I have noticed that scrolling on large todo or done files is painful. The more you move towards the end of the file the slower. So it looks like the scrolling might come to a premature halt on large files because at a certain point the scrollbar does not get updated any more.

Looks like there is a scroll buffer that dynamically adjust by doubling (buffer is small when you start at the top is doubled when you reach the bottom of it to accomodate more stuff, and then again and again, which is visible from the scrollbar moving part that starts big and halves and halves its length as you scroll down).

[ransome1]

@callegar

In theory the list initially contains a small amount of all the todos, intended to fill the window. This is due to performance reasons. Loading a list of 538 todos on app start would slow down the app a lot. Then once you scroll and almost reach the bottom, another 20 todos are loaded and appended to the end of the list. This should go on until no further todos can be loaded. In your case this should be 538 rows.

I created a fake list of almost 1.500 todos and tried to reproduce this. Unfortunately I havn't been lucky yet. I was wondering if this really might have something todo with the performance of our machines.

My questions are:

• Are you experiencing this every time you scroll or only sporadically?
• Are you only experiencing this in your done.txt file?
• Are you also experiencing this in the pre-release: https://github.com/ransome1/sleek/releases/tag/v2.0.3-rc.1

This pre-release adds an important function of React, which is suppose to remember element, which have already been rendered and avoids the re-rendering. This should solve at least improve the laggy scrolling up to a certain degree. Feel free to check this. Also please give me a quick feedback, if the pre-release changes anything on the initial issue here.

[callegar]

The 2.0.3-rc1 release appears to be faster, which is nice! Thanks.
Still I am encountering the same issue. Not always, but frequently, when you scroll down sleek appears not to realize that there are more rows to load. I'll try to check if in the rows that do not get loaded there may be something strange confusing sleek.

[callegar]

Possibly important update:

I have made more tests. The issue seems to be triggered more frequently on slow machines and to be related to the speed by which you scroll down. If you are careful to scroll slow enough, then you do not see the issue.

I have a hypothesis about the issue, but it may well be wrong.

The action to load more todos seems to be triggered when you scroll down, but a bit before the scrollbar gets to its actual bottom. The first time it happens when the scrollbar is about midway, then when the scrollbar is at about 3/4, then when it is at 7/8, then at 15/16 or so. It may be the case that if you scroll fast, the trigger point gets passed without sleek realizing. And then obviously "fast" is going to be relative to the speed of your machine. So it may be "undoably fast" on a modern machine, which may explain why you cannot reproduce the issue.

[ransome1]

That's a good observation and it might actually be causing this. Although I didn't come up with a waterproof solution yet, I changed two things. First of all, the trigger on reloading todos is fired a bit earlier and second the amount of todos reloaded has been increased slightly. Both with the intention to give sleek a bit more time to reload while scrolling and prevent missing the trigger point. It is a long shot, but can you please give this adjustment a try in your environment? https://github.com/ransome1/sleek/releases/tag/v2.0.3-rc.2

FYI I still havn't been able to reproduce it. Not even on my old i3 Thinkpad with a huge list. I also activated 6x CPU throttling in the Developer tools and could not cause this issue.

But I slightly remember, that this behavior happened to me a couple of months ago. So I absolutely positive it is an actual issue, I just need to reproduce it in order to fix it.

[callegar]

Jumped to RC3. Still seeing the issue unfortunately.
In some occasion, when you scroll at a certain point rather than augmenting the list the scroll cursor goes down to the end. Once this has happened there is no way to recover, if you scroll up and then down you do not trigger any augmentation anymore.
My machine is an Intel Haswell laptop i7-4750HQ CPU. Wonder if the desktop env might also play a role in this. I am on KDE Plasma with a Wayland session. Slightly more than 600 completed todos in the done file.

[ransome1]

@callegar I was able to reproduce this in a specific case. If I had 2 files open in sleek and scrolled down to the bottom of one, then switched to the other file (which also had significantly more entries), the reloading of more rows would not work.

Is it possible, you too were working with 2 files?

Anyways, can you please give this pre-release a try and let me know, if the issue still occurs on your environment?

[callegar]

Yes, I always have two files open in two tabs: a todo file and a largish todo_done file with the last month completed and archived tasks.

I'm now downloading the prerelease to test.

[ransome1]

Has been released as part of 2.0.4: https://github.com/ransome1/sleek/releases/tag/v2.0.4

If the issue is solved on your end as well, please close this thread. Thanks.

[ransome1]

I will close here. If it doesn't work on your end, feel free to re-open.