Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xviewer takes very long (>> 1 minute) to display a small 91kB Doxgygen generated .png image #146

Open
MatNieuw opened this issue Sep 19, 2021 · 4 comments

Comments

@MatNieuw
Copy link

 * Xviewer version 3.0.2
 * Distribution Mint 20.2 XFCE

Issue
Xviewer takes very long (>> 1 minute) to display a small 91kB Doxgygen generated .png image

Steps to reproduce
In a terminal, enter "xviewer struct_a_freq_shift__coll__graph.png" in the directory where the file is.
No errors are shown in the terminal.

Expected behaviour
Quick display.

Other information
pix and inkscape display the same file very quickly. System has AMD Ryzen 2400G with 32 M DRAM.

struct_a_freq_shift__coll__graph

@programmer-ceds
Copy link
Contributor

I right-clicked on your image and saved it to my PC (Linux Mint 20.2 Cinnamon).

xviewer (V3.0.2) opens the file almost instantly. Perhaps there is some reformatting of the image by the website? Can you put the image on Google Drive or similar and post a link to it? Then we are all definitely working with the same file. Alternatively md5sum shows the MD5 checksum for the file that I have saved as a5e982a667ef1ba7115cee5fff28bb61

@MatNieuw
Copy link
Author

My MD5 checksum is the same, so the file should be OK.
However, today I do not have the problem. This is the same machine, same directory, no updates since reporting the problem; but it was completely powered down overnight.
Yesterday when I first noticed it (clicking on the file in Thunar), the machine was still running Doxygen with a 100% CPU load (8 threads), and this file was one of those already produced. When Doxygen was finished, I still had the problem, so I copied the file to a different directory (as a diagnostic), and it had the same problem there, with CPU load 0. Disk and memory space enough.
I did see other errors too, like it failing with a malloc(),but not reliable reproducable. It did produce journalctl entries of that, if they are any help I can try to fish them out.

@programmer-ceds
Copy link
Contributor

So is this not perhaps an OS problem? If you can re-engineer the situation will other programs (pix, GIMP for example) open the file as quickly as they normally do?

@ygerlach
Copy link

ygerlach commented Jan 5, 2025

This sounds like this bug: #114

Do you have many (ganerated) pictures inside that folder? Try to copy the file into an empty folder and check if it loads fast.
Can you check the commandline of xviewer?

cat /proc/$(pidof xviewer)/cmdline | xargs -n 1 -0
# or
cat /proc/$(pidof xviewer)/cmdline | xargs -n 1 -0 | wc -l

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants