Memory leak (closing image editor)

[xnview]

tried on Win7 with default settings, and all is ok, open and close image file in edit mode, stay around 72Mb and 22Mb if deselect it in browser...

Deselect it in the browser?
What do you might mean by that?

In the browser i deselect the file

[Wormwood]

Additional info:

I checked on 14MP JPG images; i.e. mem for each: 41.45 MB.

Whenever I open an image to the image editor, XnViewMP uses abt. 47 MB more mem.
When I close the image without having done anything ... (guess! )... the mem isn't given back.

Greetings,

I can confirm the exact same thing happening with the latest XnView (1.10.3) under Devuan Linux on a machine with 8 GB of RAM.
Memory usage increases rapidly every time a file is opened (viewed) from thumbnail browser. Going back to browser and re-opening the same image in View does not increase RAM consumption, but opening a different image does.

Scrolling through the images in View mode slowly increases RAM consumption even further. If you go back to Browser, and then try to view a file adjacent to another, big file and then try to scroll into this big file, you will accumulate memory usage every time you do that, which is very noticeable.

The memory is NOT flushed under any of these circumstances, it just keeps going up. It looks like these image instances are never cleared up, until the program is closed (obviously). Pretty sure this isn't supposed to happen...

Unfortunately, disabling thumbnail generation for the whole folder does not help (it only reduces memory usage when thumbnail generation is involved), nor does unselecting an image in Browser mode.

[Wormwood]

It seems that the issue is caused by XnView opening tabs with images in the background even if tabs are hidden. 'View -> Tab -> Show' makes them visible, and closing them all either manually or via 'File -> Session -> Unload all' frees up the memory down to a reasonable amount, as expected.

I think this is what Pierre meant by 'deselecting the file in browser'. However, it's only a workaround - I wonder if it's possible to stop the tabs from accumulating if you don't want them. In many programs featuring tabbed interface, disabling or hiding tabs usually gives you a single 'tab' to work with. In XnView, it only hides the tabs but they still accumulate, which leads to this kind of confusion.

[jkm]

What is being described in Wormwood's post is clearly NOT a memory leak, it is user error.

The increased memory usage occurs because images are opened in the viewer, and are NOT being closed by the user. So they remain open forever, and memory usages increases with each new image open. This is correct behavior.

This would only, I think, occur if the user has disabled tabs (so the viewer instances are not visible) and then switched back to the browser window (such as by clicking the Browse button in the toolbar) instead of actually closing the image, by clicking the toolbar close button or hitting the shortcut key for cmd_close.

(One could make the argument that XnViewMP should not allow users anything more than a single viewer instance if tabs are disabled, and/or inhibit switching away from an open viewer instance if tabs are disabled. That would eliminate the possibility of this sort of unthinking behavior on the part of some users. But some other users would scream if this change were made.)

So Wormwood, in your case, actually close the viewer, instead of leaving it open. Then there's no increased memory usage. Use a viewer toolbar button or viewer shortcut key for cmd_close.

I am not sure this is what the OP is talking about. The OP repeatedly uses the word "close" in reference to the viewer, stating he is closing the image. But he does not specify exactly how he is "closing" the image. If he actually is closing the image viewer, then it's not what Wormwood is describing. If he just thinks he is closing the image and instead is actually merely switching back to the browser, then it's user error.

If when the OP is experiencing the problem, if he does View->Tab->Show:enabled does he see a bunch of open viewer instances or not?

[Wormwood]

Indeed, in my case it's user error due to the slightly unexpected GUI behavior, not a genuine memory leak (and I'm glad this is the case).

This would only, I think, occur if the user has disabled tabs (so the viewer instances are not visible) and then switched back to the browser window (such as by clicking the Browse button in the toolbar) instead of actually closing the image, by clicking the toolbar close button or hitting the shortcut key for cmd_close.

That's correct, this is almost exactly what I was doing. Only I was using the Enter key.

So Wormwood, in your case, actually close the viewer, instead of leaving it open. Then there's no increased memory usage. Use a viewer toolbar button or viewer shortcut key for cmd_close.

Well yes, I already figured it out, but thank you. I assume one can also assign a hotkey for 'Session -> Unload all' and use that, but it's still not very convenient. I would really appreciate if the actual way of disabling the tabs was implemented. Like I said in the previous post, many programs that feature this kind of multi-tab functionality usually allow the user to disable tabs altogether if desired, instead of just hiding them as interface element but retaining the functionality. Perhaps we can have 'Tab -> Disable' alongside 'Tab -> Hide' for this behavior? Or an option in the settings - 'DIsable tabs instead of hiding'? That would be nice.

I am not 100% sure this is the same problem the OP is facing either, but it may well be the same case because the pattern he is describing matches what I experienced exactly, i.e. same image = no RAM increase, different image = RAM increase. The wording he uses may also be due to the same confusion that I had, as I was also quite sure I was closing the View by going back to the Browser, when in fact I was only switching to Browser from another tab.

The only way to know for sure if this is the same problem, is to wait for OP to post a response on this, I guess.

[jkm]

Well yes, I already figured it out. I assume one can also assign a hotkey for 'Session -> Unload all' and use that, but it's still not very convenient.

Yes. I think what's convenient is to actually close the viewer.

I would really appreciate if the actual way of disabling the tabs was implemented. Like I said in the previous post, many programs that feature this kind of multi-tab functionality usually allow the user to disable tabs altogether if desired, instead of just hiding them as interface element but retaining the functionality. Perhaps we can have 'Tab -> Disable' alongside 'Tab -> Hide' for this behavior? That would be nice.

Personally I think the ability to hide tabs whilst still maintaining multi-viewer capability is very peculiar. If no-tab-mode was also single-viewer-mode that would seem perfectly natural to me, but some users would go crazy. But you'd be surprised at the vehemence with which users have in the past insisted on being able to hide parts of the UI, even parts that are very small, in the name of saving screen space and streamlining their experience. Or perhaps you wouldn't, since you want to hide tabs yourself. The app already has more options that any other viewer I can think of. It's impossible to please everyone unfortunately.

You obviously did a certain amount of investigation (more than a lot of users, to be honest) to find out how to disable tabs. It was just an unfortunate assumption that disabling tabs also made the app single-document-only.

The app has been developed over a long period of time, it has some idiosyncrasies as any single-developer application does (look at Irfanview!), and it has an extremely large number of options. And virtually everything is undocumented. So it's extremely common for new users to go astray and get themselves into odd or unexpected situations, or miss the forest for the trees. So this was yours. Absolutely no need for you to feel bad about it. As I said, it's almost expected. Although I confess, this is one I haven't seen before.

But because of all those options, the app can be configured to support most use cases or preferred user behaviors. Even yours, actually... Read on:

The wording he uses may also be due to the same confusion that I had, as I was also quite sure I was closing the View by going back to the Browser, when in fact I was only switching to Browser from another tab.

By default, the ESC key closes the Viewer, like it acts as a "close" for many Windows dialogs. In many apps, Enter often opens files; it hardly ever closes them.

But if you like, you can rebind cmd_close in the viewer to be the Enter key, and then the app will actually do what you thought it was doing. It won't be single-document, but because the thing you want to do to close the viewer will actually close the viewer, the effect for you will be the same.

It's also worth mentioning that there's a setting in Settings:General called "Save session on program exit". If that is set to Always instead of Never, then the open images (and thus memory usage) will even persist across application restarts.

The app also has the equally unique "Switching modes" settings in Settings:Interface:Switching modes. You can make the Enter key do things in there and override double-click behavior, so that's also something to be mindful of. You should investigate those settings, to ensure you have a handle on how to make the app behave or misbehave as you like. Make sure you set Enter to be Browser<-->Viewer if you want it to cleanly function as I describe above.

A funny coda is that even if you do the above to rebind the Enter key to support your behavior, you will STILL be able to use ESC to also close the Viewer. Because it's basically a "universal close/dismiss" key.

Anyway, hopefully this helps...

The only way to know for sure if this is the same problem, is to wait for OP to post a response on this, I guess.

Agreed.

But I observe the OP did also say this:

Now (without having done anything in editor) close image editor.
Would expect MP's mem usage to drop 48MB again.
But does not!
Opening the same file again: No additional mem usage.
Open a different file: Additional mem usage.

This makes me suspect that it is very possible nji9 is making the same mistake you did. That would not surprise me at all. However, unlike you, nji9 is not a new user, and has been using the app for over 5 years.

I guess we'll see... Cheers.

[xnview]

The memory is NOT flushed under any of these circumstances, it just keeps going up. It looks like these image instances are never cleared up, until the program is closed (obviously). Pretty sure this isn't supposed to happen...

Please send us your xnview.ini, and describe exaclty what you do?

[jkm]

The memory is NOT flushed under any of these circumstances, it just keeps going up. It looks like these image instances are never cleared up, until the program is closed (obviously). Pretty sure this isn't supposed to happen...

Please send us your xnview.ini, and describe exaclty what you do?

I think Pierre didn't read the last three posts. Nothing for you to look at with Wormwood, Pierre.

[Wormwood]

Thank you for the kind feedback! I don't really feel bad about posting this, on the contrary I hope that my post will be helpful to anyone who faces the same problem. I actually have been a long time IrfanView user before coming to Linux and using XnView MP, and I definitely agree that both programs have a unique character to them while offering an excellent feature set - which is why I like them.

Regarding the Enter key, that's actually what I was using it for - it's already set to switch between the Browser and Viewer modes, so I assumed that when the tabs are not visible, the Viewer simply closes when going back to the Browser. But because of the way the Hide Tabs function works in XnView, this was not the case. It's a little unorthodox and counter-intuitive, but I'm glad that we sorted it out. Binding the Enter key to cmd_close in the Viewer appears to achieve the desired behavior. Once again thank you for the swift assistance.

But I observe the OP did also say this:

Now (without having done anything in editor) close image editor.
Would expect MP's mem usage to drop 48MB again.
But does not!
Opening the same file again: No additional mem usage.
Open a different file: Additional mem usage.

This makes me suspect that it is very possible nji9 is making the same mistake you did. That would not surprise me at all. However, unlike you, nji9 is not a new user, and has been using the app for over 5 years.

I guess we'll see... Cheers.

Yes, and he also describes how RAM usage increases and is not given back to the system. So I think it's likely to be the same case. I think I also saw a few similar unresolved threads here about the Viewer's memory usage that could also be related.

The memory is NOT flushed under any of these circumstances, it just keeps going up. It looks like these image instances are never cleared up, until the program is closed (obviously). Pretty sure this isn't supposed to happen...

Please send us your xnview.ini, and describe exaclty what you do?

Hello Pierre, the problem was in fact do the slight UI confusion I had. It is not a bug. We have since resolved it, but you might consider adding an option in XnView to actually disable tabs instead of just hiding them (while keeping the old behavior as default in order not to confuse the old users).

[nji9]

... and here I am again... just noticing the answers.

By "closing" the editor I meant just a double-click on the image,
which seems to be the same as switching to browser and leaving the image opened/ in mem.
As when I have tabs shown... all are there... consuming my beloved mem

Actually the tabs wheren't shown with me (I can't remember ever having hidden them).

To tell the truth I never would have expected that when "closing" an image
by the same way as opening/ showing it (double-click)
that it would remain opened in background.
I really wonder if I'm the only one noticing (after 5 years usage ) the mem consumption?

OK, as usually I have just one image opened, I don't need the tabs shown.
But... I don't see a close button anywhere!
Hopefully someone will tell me?
ESC will be a bit archaic to my taste

[jkm]

By "closing" the editor I meant just a double-click on the image,
which seems to be the same as switching to browser and leaving the image opened/ in mem.
As when I have tabs shown... all are there... consuming my beloved mem

Right, so user error. Because that is not "closing".

Actually the tabs wheren't shown with me (I can't remember ever having hidden them).

But you did hide them.

I really wonder if I'm the only one noticing (after 5 years usage ) the mem consumption?

OK, as usually I have just one image opened, I don't need the tabs shown.
But... I don't see a close button anywhere!
Hopefully someone will tell me?
ESC will be a bit archaic to my taste

After 5 years usage, someone needs to tell you?

So hit Escape, or bind the cmd_Close shortcut to a mouse button, OR...

But... I don't see a close button anywhere!

That's your own choice.

Why don't you customize the toolbar for the viewer and ADD a close button?

[nji9]

After 5 years usage, someone needs to tell you?

Your remark is anything but kind, Sir.

Moreover doesn't it make you think that for closing an editor (and not accumulating the mem),
you can't use the same command than for opening it (I already wrote above)?

If that's a "user error" then the expected XnViewMPs must be some kind of Klingons...

Instead you have to use archaic ESC, or have to define your own button?

(No... I guess it won't make you think... )

[jkm]

Sorry, but you’ve exhausted my patience.

[xnview]

OK, as usually I have just one image opened, I don't need the tabs shown.
But... I don't see a close button anywhere!

Even if tabs are hidden, a tab is opened.
When tabs are hidden, i agree that you have no way to see if you have other tabs (TAB to switch)
So perhaps an option to close image tab when you switch to browser?

[jkm]

So perhaps an option to close image tab when you switch to browser?

Not the best way to do it, I think.

Instead, probably the best way to call such an option is “Limit application to a single viewer when tabs are hidden”.

That’s what the issue is about. For people who want to treat the application as if it can only open a single image, just limit it to open a single image.

Closing the last image when switching to the browser causes two problems:
- It contradicts the Switching Modes concept
- It prevents people who have an open unsaved image (that they might be editing) from switching back to the browser to check something in the catalog, info panel, etc.

If they then switch modes on a different image, it will close the previous image, prompting to save if necessary.