1.80: Two Fullscreen modes?

[helmut]

I still find 2 fullscreen modes confusing.

As written above the two fullscreen modes are only a problem if they differ. If they are similar, you won't notice.

"Browser > Fullscreen > Viewer" - Seems to work as named.
"Browser > Viewer > Fullscreen" - Seems to work as named.
"Browser <> Viewer" - Seems to work as named.
"Browser <> Fullscreen | Viewer <> Fullscreen" - This does not work exactly as named. Nobody will know what it does unless they experiment with it.

What you have listed above has not much to do with the two fullscreen modes. The "Switching mode" options are new options which allow users to fine-tune the way XnView switches from one mode to another. Modes are the same as in 1.74: Browser, Image View, and Fullscreen.
This fine-tuning is mainly intended for more sophisticated users, most people will keep the default settings. You have understood 75% of them, this shows that the settings are clearer now and are not too bad. Sure enough we should make these settings as simple as possible, but currently I can't see a way.

[marsh]

I don't think I'm confused about the mode names now. I had just started to look at the terminology on them. Eventually, any difference in fullscreens will be noticed. The only new suggestion I have is to completely subordinate new fullscreen function under "Dual Screen Mode" (where I assume it is meant for, I don't know...I only use 1 monitor).

[Olivier_G]

From a technical point of view, if I understand correctly:
A. It is impossible to draw things on the Browser's Fullscreen lite (ie: crop box, etc...).
B. It is impossible to use Dual Monitor with Viewer's MDI Fullscreen.
=> therefore, you can't have 100% exactly the same behaviour if you want to keep both features (Pierre, please confirm or correct those points).

There are also performance issues that lead to the creation of the faster Fullscreen lite. However, my own feeling on this (using Process Explorer and FileMon) is that by using a new Buffer system and optimizing switchings, both modes should give the same performance.

What to do?
1. Always use Fullscreen lite (ie: no edition in fullscreen)
2. Always use Fullscreen MSI (ie: no dual monitor feature)
3. Use Fullscreen lite for Browser and Fullscreen MDI for Viewer (inconsistent, currently used)
4. Use Lite/MDI depending on 'dual monitor' setting
(ex: OFF=>MDI; ON=> Fullscreen lite on 2 screens OR you could choose independant Browser/Viewer on screen 1 and Fullscreen lite on 2)

Both 'dual monitor' and 'cropping in fullscreen' are important to users, therefore [1] and [2] should be avoided.
I think that [4] is the best solution provided MDI can reach the speed of Lite (requires major changes in the Buffer system, Windows switching...). Your opinion?

[Olivier_G]

Some measurements on my computer (AMD Athlon 2500+/1024MB/200GB 7200rpm/Win XP-SP2/1600x1200 display) with XnView 1.82.4.

Fullscreen lite
- Load+Display a 8MP(2300x2400) TIFF 24bits of 22MB: CPU=0.15s (with 1600x1200 LQ resize) / HD=0.15s
- Load+Display a 6MP(3072x2048) JPEG of 1.6MB: CPU=0.3s (with 1600x1200 LQ resize) / HD=0.3s
..........for an 'EXIF turned' 6MP JPEG: HD=0.3s / CPU=1.3s (wich means 6MP EXIF rotation: CPU=1s!)
(for the 6MP JPEG)
- 1600x1200 LQ resize: CPU=0.050s (nearest neighbour)
- 1600x1200 HQ resize: CPU=0.300s (bilinear)
Notes:
- HD and CPU times are mostly parallel (ex: the 0.3s HD duration for the JPEG is mostly due to the CPU=0.25s of decompression).
- Although those measurements are important, the image Buffer mechanism is even more important regarding responsiveness.
- Exif rotation CPU depends on image size, whether - if I am right - resize depends on display size.
- Currently the Image Buffer is for Load&EXIF rotation. There is no Display buffer. That's how you can get those individual resize numbers to support that MDI can be as fast as Lite.

Now, about MDI Viewer (6MP JPEG)
- Windowed->fullscreen resize LQ: CPU=0.100s
- Fullscreen->windowed resize LQ: CPU=0.050s
- Windowed->fullscreen resize HQ: CPU=0.600s (same as 2 HQ resize!!!)
- Fullscreen->windowed resize HQ: CPU=0.300s
- When you double click from Browser, the image will be reloaded (whereas the Buffer is used in Lite).
- There is no 'Delayed HQ' in MDI

My conclusion about all this: MDI fullscreen could be optimized to be as fast as Lite fullscreen.
- MDI window<->fullscreen is as fast as Lite in LQ.
- MDI switching can probably be optimized (1 unnecessary resize for window->fullscreen? &Translation?), Buffer and 'Delayed HQ' could be implemented for MDI.