Menu delay on cold start

[Drahken]

I'm not sure if this is a bug, a design flaw, or merely an annoyance, so I'll put it here.
I have xnview set to launch in basic mode and have turned off the toolbar to maximize screenspace. Whenever I launch xnview for the first time after rebooting, then click on a menu such as file or tools, there is a distinct pause before the menu will open (although the program itself opens instantly). Sometimes this pause only lasts a second or 2, sometimes it lasts as long as a full 30 seconds (on a 2Ghz comp!). The length of the delay seems dependant mainly how how much memory and resources are being used by whatever other progs I have running at the time. After the first launch, the menus will open instantly until the next time I reboot.
Is this a result of the plugins caching that was introduced in the 1.8 versions to speed up launch time?
Can the delay be removed in future versions, or is it just something we'll have to live with? (It's just a minor annoyance, and it's much better having it occur once per reboot than during every launch be slow like it was in older versions. )

This occurs in both 1.8.03 and 1.8.01, and presumeably all other 1.8x versions.

[xnview]

I'm not sure if this is a bug, a design flaw, or merely an annoyance, so I'll put it here.
I have xnview set to launch in basic mode and have turned off the toolbar to maximize screenspace. Whenever I launch xnview for the first time after rebooting, then click on a menu such as file or tools, there is a distinct pause before the menu will open (although the program itself opens instantly). Sometimes this pause only lasts a second or 2, sometimes it lasts as long as a full 30 seconds (on a 2Ghz comp!). The length of the delay seems dependant mainly how how much memory and resources are being used by whatever other progs I have running at the time. After the first launch, the menus will open instantly until the next time I reboot.
Is this a result of the plugins caching that was introduced in the 1.8 versions to speed up launch time?
Can the delay be removed in future versions, or is it just something we'll have to live with? (It's just a minor annoyance, and it's much better having it occur once per reboot than during every launch be slow like it was in older versions. )

Strange, plugins caching is to speed up startup not slow down
Could you try without plugin folder??

[Drahken]

Actual program startup is fast (as long as you don't actually want to do anything with the prog ), and full startup is fast after the initial startup.

I'll have to wait till the next time I reboot.


Question: How often does xnview re-cache the plugins, or check for new plugins? Is it once per reboot, or once per month, or once period, or...?

[Drahken]

I just tried renaming the plugins folder and launching xnview, and still got the menu delay. Also, it's not only after a reboot, but also after I've used a lot of memory for other programs. It definitely appears that xnview is caching something when it does that, and that said cache gets erased after a reboot or after using a lot of memory for other things.

[xnview]

I just tried renaming the plugins folder and launching xnview, and still got the menu delay. Also, it's not only after a reboot, but also after I've used a lot of memory for other programs. It definitely appears that xnview is caching something when it does that, and that said cache gets erased after a reboot or after using a lot of memory for other things.

So not a problem of plugins, if you start xnview without starting browser, do you have the same delay??

[Guest]

Hmm. Are you using any other language that the build in English! The delay might be language file related.

[ckv]

And that was me, by the way. I tested with Finnish language file, but there's no delay.

I have experienced lot of menu bugs while using different language file, but that was in 1.7x

[Drahken]

So not a problem of plugins, if you start xnview without starting browser, do you have the same delay??

I never start the browser. I launch in basic mode, then click a menu to open an image into viewer mode.

The delay occurs when clicking file, tools, etc on a cold start, or after many resources/much memory have been used for other progs. Also, it only occurs the first time you click any menu. For example, if you click file and then tools, you will get the dealy when you click file, but not when you click tools. (If you clicked tools first, then file, then you would get it on tools but not on file.)


I use english, and always get the minimal file so as not to waste time downloading a bunch of stuff (ie, other language files) that are useless to me.

[xnview]

So not a problem of plugins, if you start xnview without starting browser, do you have the same delay??

I never start the browser. I launch in basic mode, then click a menu to open an image into viewer mode.

The delay occurs when clicking file, tools, etc on a cold start, or after many resources/much memory have been used for other progs. Also, it only occurs the first time you click any menu. For example, if you click file and then tools, you will get the dealy when you click file, but not when you click tools. (If you clicked tools first, then file, then you would get it on tools but not on file.)


I use english, and always get the minimal file so as not to waste time downloading a bunch of stuff (ie, other language files) that are useless to me.

Only file menu?? When opening File menu, i check for WIA device to enable or disable "Acquire from WIA..."

[Drahken]

Also, it only occurs the first time you click any menu. For example, if you click file and then tools, you will get the dealy when you click file, but not when you click tools. (If you clicked tools first, then file, then you would get it on tools but not on file.)

It occurs the first time you open any of those menus (file, view, tools, window, info) after a reboot or after too many resource have been used for other progs. After you open any of those menus once, none of them will do it again until the next reboot or memory re-allocation.

[xnview]

Also, it only occurs the first time you click any menu. For example, if you click file and then tools, you will get the dealy when you click file, but not when you click tools. (If you clicked tools first, then file, then you would get it on tools but not on file.)

It occurs the first time you open any of those menus (file, view, tools, window, info) after a reboot or after too many resource have been used for other progs. After you open any of those menus once, none of them will do it again until the next reboot or memory re-allocation.

Someone has the same problem???

[ckv]

Drahken, have you monitored XnView with taskmanager or even better with Process Explorer if the XnView is using significant amount CPU or memory, while the menu is opening? And also, (this is a long shot) have you tryed to use clean ini / install?

[Drahken]

have you monitored XnView with taskmanager

I did that just now. On a cold start, it starts at 5.9M, then jumps to 6.9M when I open the menu. On a warm start, it starts at 6.2M and jumps to 6.9 when I open a menu. It definitely seems to be storing/caching something.

have you tryed to use clean ini / install?

No, but this has been this way since I first installed it.

[ckit]

I can't reproduce this bug using XnView 1.80.3 on Windows 2000 SP4 r1v2.

According to "Process Explorer" XnView is using only 4.8Mb with WinXP menus turned off.

[xnview]

have you monitored XnView with taskmanager

I did that just now. On a cold start, it starts at 5.9M, then jumps to 6.9M when I open the menu. On a warm start, it starts at 6.2M and jumps to 6.9 when I open a menu. It definitely seems to be storing/caching something.

have you tryed to use clean ini / install?

No, but this has been this way since I first installed it.

Perhaps i can send a version without WIA check, could send me a PM