I hope you are doing well. Congratulations on the new release of XnView MP.
Unfortunately, I have a rather strange bug to report. It's a bit complex, I tried my best to guide you through the required steps to reproduce it. Feel free to request more details and ask for my assistance (running a debug/test version).
Windows 10 Pro 64-bit, XnView MP v0.98.3 64-bit
This bug is available in many past releases of XnView MP, probably since the first release? I also tried solving this issue with a fresh install of XnView MP (64-bit installer). Comparing the settings of the fresh install with my regular setup of XnView MP helped me to identify the setting that causes the issue.
Current behaviour:
In browser mode, XnView MP generates a constant high CPU load and shows an empty progress bar with a varying width when certain conditions are met (described in the next section).
How to reproduce:
The following settings must be met to trigger the bug:
- In [Browser > Filelist > Custom filter] check 'visible' for 'Folders'
- In [Browser > Filelist > Custom filter] uncheck 'visible' for 'All other files'
In Browser mode enter into a folder that meets the following conditions:
- the folder contains more images than XMP can display icons on screen at a time
- the folder contains at least one subfolder represented by a folder icon in the listing
The folder content is read to generate the file listing, a progress bar visualizes the process. On completion, the progress bar is removed.
Now browse the folder by [Cursor-Down] or [Page-Down] key. When a new set of icons needs to be drawn on the screen, the progress bar reappears and a constant high CPU load is generated. The progress bar remains empty (the bar never fills) and its width changes depending on the highlighted image.
The empty progress bar and the constant high CPU load disappear only when highlighting a subfolder icon in the file list once. From that moment the file list can be browsed without the described symptoms. However, pressing [F5] to reread the folder has the issue reappear.
This bug does not occur when one or both of the following conditions is met:
- All icons of the file listing (images/folders) can be displayed on one screen (no scrolling required)
- The file listing does not contain any subfolders
Setting 'All other files' to 'visible' in [Browser > Filelist > Custom filter] prevents this bug from appearing, but strangely this then affects the 'Add new files to end of list' function like follows:
When in Fullscreen or View mode, save a currently viewed image to a new file using the same filename appended by any letter (test.jpg > testa.jpg). The new file is always added to the end of the file list, regardless of the setting 'Add new files to end of list' en- or disabled.
Expected behavior:
- XnView MP should not generate any load on the CPU once the creation of the filelist for browser mode is completed
- No empty progress bar with varying widths should occur
- 'Add new files to end of list' should not be affected by 'All other files' of [Browser > Filelist > Custom filter]