Non-ascii path in xnview.ini (History) causes xnviewMP to start slowly

[fireattack]

Main bug: if you have an non-ascii pathees in setting like history, XnviewMP starts very slowly. This bug seems to be in XnViewMP for years.

I can reproduce in as early as 1.6.4.

I suspect it fondamentally the same bug as viewtopic.php?f=62&t=48026.

Steps to reproduce:
1. Create a xnview.ini with the following settings.

Code: Select all

[Start]
History=D:/\x4e2d\x6587/

2. Start XnViewMP

Notice it starts very slowly compared when you have something like

Code: Select all

[Start]
History=D:/Pictures/

Also, since 1.8.1, the behavior of this slowdown changes when you start xnviewmp.exe with a dir argument (e.g.

Code: Select all

xnviewmp.exe .

).

In 1.4.x~1.8.0, it will immediately show an blank window and then loads after 2 seconds.
In 1.8.1~now, it will only show the program in the taskbar but no window is showing (blank or not), until after2 seconds.

[xnview]

i'm not able to reproduce. "very slowly", some seconds more?

[fireattack]

when there is non-ascii values in History, it takes about 1 to 1.5 seconds for the window to show after you double click the exe.

When there is no such values in ini, the window shows immediately.

See the video below for a quick demo.

[xnview]

i've tried on 2 windows 10, and can't reproduce

[fireattack]

i've tried on 2 windows 10, and can't reproduce

The difference probably isn't too significant if your machine is very fast -- can you use a stopwatch and measure the difference?

You can use these two fully populated INIs I prepared to test. I can reproduce this bug on two different machines:

XnViewMP.ini.zip

(10.16 KiB) Downloaded 98 times

Also, what do you think about the second part of the bug?

when you start xnviewmp.exe with a dir argument (e.g.

Code: Select all

xnviewmp.exe .

In 1.4.x~1.8.0, it will immediately show an blank window and then loads after 2 seconds.
In 1.8.1~now, it will only show the program in the taskbar but no window is showing (blank or not), until after2 seconds.

This is a more recent regression and should be easier to test.

[xnview]

The difference probably isn't too significant if your machine is very fast -- can you use a stopwatch and measure the difference?

You can use these two fully populated INIs I prepared to test. I can reproduce this bug on two different machines:
XnViewMP.ini.zip

Not easy to see, but sometimes i have 0.4sec more with History
I think that its in Qt to initialize chinese font

Also, what do you think about the second part of the bug?

when you start xnviewmp.exe with a dir argument (e.g.

Code: Select all

xnviewmp.exe .

In 1.4.x~1.8.0, it will immediately show an blank window and then loads after 2 seconds.
In 1.8.1~now, it will only show the program in the taskbar but no window is showing (blank or not), until after2 seconds.

This is a more recent regression and should be easier to test.

it's related to this issue. The window is shown when window initialization is made.
Is it a problem?

[fireattack]

The difference probably isn't too significant if your machine is very fast -- can you use a stopwatch and measure the difference?

You can use these two fully populated INIs I prepared to test. I can reproduce this bug on two different machines:
XnViewMP.ini.zip

Not easy to see, but sometimes i have 0.4sec more with History
I think that its in Qt to initialize chinese font

Also, what do you think about the second part of the bug?

when you start xnviewmp.exe with a dir argument (e.g.

Code: Select all

xnviewmp.exe .

In 1.4.x~1.8.0, it will immediately show an blank window and then loads after 2 seconds.
In 1.8.1~now, it will only show the program in the taskbar but no window is showing (blank or not), until after2 seconds.

This is a more recent regression and should be easier to test.

it's related to this issue. The window is shown when window initialization is made.
Is it a problem?

The problem with this new approach is that when the window does not show immediately in foreground (even just as a blank window), it's easy to misclick other window or alt+tab to the wrong window when you operate fast. And it feels very sluggish because you would expect the taskbar and the window to show together, always.

If the goal is to prevent white flash, I think we can just let xnview mp to not show up at all (not even in the taskbar) until it's ready -- which is exactly what it still does when you run xnviewmp.exe without arguments.

This new behavior, no window shows but taskbar shows, only happens with dir arguments, why?

[user0]

This new behavior, no window shows but taskbar shows, only happens with dir arguments, why?

try to open large file, eg >50Mb

[xnview]

This new behavior, no window shows but taskbar shows, only happens with dir arguments, why?

here with or without argument, XnView is shown in taskbar but no window

I'll add a setting to disable it

[fireattack]

This new behavior, no window shows but taskbar shows, only happens with dir arguments, why?

here with or without argument, XnView is shown in taskbar but no window

I'll add a setting to disable it

Thanks!