Bug 158985 - Make thumbnail generation multi-threaded
Summary: Make thumbnail generation multi-threaded
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: easyHack, skillCpp
: 158956 (view as bug list)
Depends on:
Blocks: Recent-Document-List Start-Center
  Show dependency treegraph
 
Reported: 2024-01-02 17:41 UTC by Hossein
Modified: 2024-01-04 15:14 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2024-01-02 17:41:27 UTC
Description:
Files that are deleted or renamed remain visible in the menu and start center even after they are deleted/renamed. To avoid having the invalid file names / thumbnails in the menus and start center, a new option, "Clear Unavailable Files" is added to LibreOffice to address the issue tdf#101302.

The previous implementation can be found in below commit, which is not multi-threaded:
tdf#101302: Add option to clear unavailable files in menu/start center 2839b604af94dbd1ee59dc6d47dc2f4c6ebd8dc6

This task here is to improve the implementation provided for the above issue by making it multi-threaded. This is the quote from Mike in tdf#101302 comment 41, which provides code pointers, before above change:

"Currently (after recent changes) thumbnail generation is performed fully in RecentDocsViewItem constructor [1]. It has two cases: where a pre-created thumbnail is present (see line 208), and when it's absent (line 167). The former one currently does not attempt to access files, only using pre-existing thumbnail and file name to draw the element in the start center; the latter tries to access the document trying to detect if the document is protected (at which case, it may be problematic when the file is unreachable - see e.g. bug 144566).

The change should:
1. Change second case to not attempt to access files, drawing default thumbnail without lock to avoid UI blocking;
2. Introduce a thread (one for all, or per-item) to access files asynchronously, detecting (a) file availability, and (b) file encryption/password protection. This should result in unavailable items being re-drawn (either as dimmed, or maybe using some overlay indicating its unavailable status), and protected ones re-drawn with lock - when that data is available. The thread should update the item's maPreview1, and use some method of RecentDocsView [2] to update specific items (note that existing RecentDocsView::Reload is not suitable, since it re-creates all the items). It should be possible to terminate the thread early, when user leaves the recent list (e.g., opens a file or switches to templates view)."

[1] https://opengrok.libreoffice.org/xref/core/sfx2/source/control/recentdocsviewitem.cxx?r=1dbed50a#123

[2] https://opengrok.libreoffice.org/xref/core/sfx2/inc/recentdocsview.hxx?r=1dbed50a#60
Comment 1 Buovjaga 2024-01-02 18:23:27 UTC
*** Bug 158956 has been marked as a duplicate of this bug. ***
Comment 2 Mike Kaganski 2024-01-03 03:54:05 UTC
Is it really needed?
The "Clear Unavailable Files" is an explicit user action. It is expected to take as long as needed to produce the requested result. If it is made async, which was what my comment was about (for a completely different thing!), you would also need to create a way to still produce a feedback to user (introduce a progress bar?).

Note that my cited comment was for a hang when displaying the thumbnails. I suggested a way to make displaying it instant, but update the icons / pictograms on it in the background. This task is completely different.
Comment 3 Mike Kaganski 2024-01-03 03:56:44 UTC
(In reply to Mike Kaganski from comment #2)
> Note that my cited comment was for a hang when displaying the thumbnails. I
> suggested a way to make displaying it instant, but update the icons /
> pictograms on it in the background.

And note, that that is still relevant. Even though you may clear the list, before it's done, the user may still experience a temporary "freeze"; and also, network-located files - actually available! - can also make experience sub-optimal because of slow network I/O. I support Telesto's opinion about incorrect resolution of original issue by creating a related, but different tool.
Comment 4 Hossein 2024-01-03 09:45:29 UTC
(In reply to Mike Kaganski from comment #2)
> Is it really needed?
> The "Clear Unavailable Files" is an explicit user action. It is expected to
> take as long as needed to produce the requested result. If it is made async,
> which was what my comment was about (for a completely different thing!), you
> would also need to create a way to still produce a feedback to user
> (introduce a progress bar?).
> 
> Note that my cited comment was for a hang when displaying the thumbnails. I
> suggested a way to make displaying it instant, but update the icons /
> pictograms on it in the background. This task is completely different.

Ok, then what do you suggest? A new issue, with a new description, or just a new title? The original issue is overly crowded, and not suitable for an EasyHack.

A new title can be: "Make thumbnail generation multi-threaded".
Comment 5 Mike Kaganski 2024-01-03 11:11:25 UTC
(In reply to Hossein from comment #4)
> A new title can be: "Make thumbnail generation multi-threaded".

I agree with a "Make thumbnail generation multi-threaded" task. I doubt that "Make "Clear Unavailable Files" in menu/start center multi-threaded" task is needed, which is what I expressed. Please decide, if my doubt is reasonable, and how exactly to proceed; any course is fine, including keeping this, because others may disagree with me. The only undoubtable thing is that *my* original idea / suggestion was for a completely different topic, so regardless of resolution of "Make "Clear Unavailable Files" in menu/start center multi-threaded", that original topic will be unaffected.