Slow interface

svefro

I have a lot of photos.

20000 or so. and i notice that as i add more faces to images tonfotos is getting slower. the scrolling list of photos is getting quite long.

The pc i have Tonfotos on is a relatively fast/ok stationary computer with a 11 gen i7. 32gig ram and a 3060ti card.

After a bit of scrolling the DOM-Tree must be huge on the loaded document.

Could you make a option to not load everyone in the same list.
Only one person at a time.

Maybe this could be a option for someone like me with a lot of images.

You could add a button to the bottom of each page that takes you to the next person.

Andrey

svefro 20 000 is not much actually, in average people use Tonfotos with something around 100 000 images, but some even with much more than that.

It is already implemented the way that not everyhing is loaded at once, ofcourse. Pictures get loaded in background as you scroll. Typical personal albums for my own family members is around 10 000 faces. I would not say it works blazingly fast with such amount of faces, but it is totally workable. When you switch to that person, it would lag for just a moment, but then works totally smoothly, you can scroll up and down without any delays.

As to PC specs, most important characteristics is speed of your C: drive. If this is just HDD, then it can be the reason for delays. The best option is SDD with m2 interface. Tonfotos stores its internal database on disk C, and uses it a lot.

What drive do you have?

svefro

Andrey
All disks are medium/fast m2 disks.

I started to notice the slowness after tagging most of my pictures.
so the lists got longer on every person.
But i still have suggestions coming in.

it is not realy-realy slow. just noticeable.
Interface jerks sometimes when i confirm names, or right click to enter person name on images.
then sometimes it is like the ui is locked for a short moment.

So i thought maybe there is a way to optimize the app for better performance on large lists.
Have you checked the DOM-tree size on large lists?

“An optimal DOM tree: Has less than 1500 nodes total. Has a maximum depth of 32 nodes. Has no parent node with more than 60 child nodes.”

Reflows are also costly on large dom-trees.

html is realy bad on long documents.
It is not easy/possible to use the same nodes over again as you scroll. (and avoid jerks in scroll position)
Things you get for free in QT/WPF and some other desktop frameworks.

But i did a quick google search and found this: https://clusterize.js.org/
Maybe something like that could work?

Andrey

svefro Thank you for the link. Clusterization of the list is interesting idea.