"Document Map" view is rendered at wrong place in 7.8.9

[gnaggnoyil]

Description of the Issue

The overlay shade effect of the Document Map view is rendered at middle of the whole window, rather than its original place

Steps to Reproduce the Issue

1. Upgrade notepad++ to 7.8.9 from 7.8.6 using x64 installer.

Expected Behavior

Document Map view shall have all its effects in right place

Actual Behavior

Debug Information

Notepad++ v7.8.9   (64-bit)
Build time : Jul 15 2020 - 20:31:49
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 10 Pro (64-bit) 
OS Version : 1909
OS Build : 18363.900
Current ANSI codepage : 65001
Plugins : DSpellCheck.dll MarkdownViewerPlusPlus.dll mimeTools.dll NppConverter.dll NppExport.dll NppSaveAsAdmin.dll 

[Ekopalypse]

I'm not sure if this is related to this issue or if it is a separate issue

Open npp without any document loaded and make sure word-wrap has been disabled.

Now enable word-wrap.

Resize the Document Map window and you will see a shadow coming out of the Main window.

[donho]

@Ekopalypse I cannot reproduce what you reported on my Windows 10 PC. It may related only to Windows 7 ?

[Ekopalypse]

@donho, I fired up my Windows 10 Virtualbox image and can confirm that I do not see the shadow coming out either.
But the issue with partly painted control, as seen in image2, is here as well.

[Uhf7]

We have two different effects here.

The first one (reported by @gnaggnoyil) I cannot reproduce. The first questions here would be:

• Does it go away when the window is moved or resized?
• Does it depend on the Windows 10 version (1909)? (Because I I'm testing on a 1607)

The second one (reported by @Ekopalypse) is an effect of word wrapping alone. The width of the Scintilla edit window portion of the Document Map is calculated arbitrarily. The goal is to match the length of lines expected in the Document Map and not the actual width of the Document Map. That's why the Scintilla edit window portion of the Document Map is most times smaller than the Document Map itself. But, if the Document Map width is reduced too much, then this Scintilla edit window portion is wider than the Document Map itself. In this case, and under Windows 7 only, the transparent overlay of the Document Map gets visible outside the Notepad++ window. Under Windows 10, the transparent overlay of the Document Map is a child window (which is impossible under Windows 7), that's why it cannot leave the bounds of Notepad++.

My first private thought to solve the problem with the word-wrapped Document Map was: Do not wrap the Document Map at all, even if word wrap is turned on. I tested it, and for me the results were OK. What I got, was a word wrapped edit window, and a not wrapped Document Map, in which the range visible in the edit window was marked orange.

So my proposal would be: Never wrap text in the Document Map. If the edit view is wrapped, it displays not exactly what is stored in the file. So let the Document Map show the reality. Of course, this can go to extremes with documents containing a single long line for example, but on the other hand, especially in those cases it may be helpful to see the reality.

My opinion: It is nearly impossible to get the Document Map wrapped at the same positions as the text document in the edit window. It depends on too many factors, like syntax highlighting and font sizes. The only way I could imagine (but not implement) is to collect all word wrapping points from the edit window and apply them manually to the Document Map, which will become a time consuming process on large documents.

[gnaggnoyil]

@Uhf7 Thanks for your reply here! No, the misplaced effect does not go away when the window is resized or moved, and will always show in the middle of the window. I'm not sure if it's related to Windows 10 version, for I haven't tested on other Windows 10 versions yet. Do I need to try on some other Windows 10 versions?

[Uhf7]

@gnaggnoyil Thank you for testing. I just got another thought. Your screen shot is 1756 pixels high, so you possibly have one of those new displays with 4K resolution. Windows tends to scale apps on those displays automatically. Perhaps the effect goes in this direction. So the next questions are:

• What screen resolution do you use?
• If you use 4K, what happens if you "Disable display scaling on high DPI settings"?

This Disable option can be found as follows (at least in the 1607 Windows version):

• Right click on Notepad++.exe
• Properties
• Compatibility tab

It looks like this (the .exe name is modified in my test environment):

[Ekopalypse]

@Uhf7 - I'm certainly no c++ programmer but I think the DocumentMap is basically a cloned view of the current document.
We can even simulate this with the second view.

So there's nothing to calculate, is there?
And as for the "shadows" - I had the impression that you can force a window control like Scintilla to take the size of the frame/window underneath it.

[Uhf7]

@Ekopalypse I think it's more complicated. The word wrapping mechanic of Scintilla is that you set wrap mode on (SCI_SETWRAPMODE), and Scintilla wraps the lines which exceed window width. The document map is kind of a cloned view, that's true, but it has a different font size than the original view and it is wrapped by Scintilla completely independent of the original view.

What Notepad++ tries here, is to calculate the window width of the Scintilla portion of the Document View using the ratio between the font size of the edit window and the font size of the Document Map. And then, the Scintilla portion of the Document Map is set to this calculated width. And then it is expected, that Scintilla wraps the text at the same points as in the original edit window.

This cannot work in my opinion, which is backed up by numerous experiments on my side. If I had found a way to solve this, I would happily created a PR showing how to do it. So, why it cannot work (in my opinion at least)? I cannot explain it very well, I always felt, that the Document Map stuff is difficult. So I try to construct the following example:

• Assume, that some words in a line are bold due to syntax highlighting.
• Assume, that the bold words have a higher pixel width than the same non-bold words in the original edit view.
• And imagine that, if the view size is decreased dramatically, the bold words are actually not rendered bold anymore, because they are too small to see that difference, so that in the tiny view the pixel width of the bold words is identical to the pixel width of the non-bold words.

The result of this are different wrapping points in the original edit view and the tiny Document Map view. This occurred constantly in my tests, so I eventually gave up the wrapped view, which means, I accepted that it can only be an approximation.

My proposal remains, don't ever wrap the Document Map, you get much more information seeing reality there than the approximated wrapped view does provide.

[Ekopalypse]

@Uhf7 - thanks for clarification and you are correct. Seems it isn't as easy as I was assuming.

[gnaggnoyil]

@Uhf7

1. My display's screen resolution is 3840x2160, and scaling factor of this display is set to 200%.
2. In 1909 appliction's HiDPI settings were changed(I believe it has been changed since at least 1809). The new setting in "Properties" -> "Compatibility" tab is now a "Change high DPI settings" button which then leads to a dpi setting dialog as shown in https://www.windowscentral.com/how-change-high-dpi-settings-classic-apps-windows-10-april-2018-update . I have always been unchecking the "Use this setting to fix scaling problems for this program instead of the one in the settings" box, and effects according to my selection of "Override high DPI scalling behavior. Scaling is performed by:" drop-down list is:
   • "System": The issue does not appear, and the whole window looks blurry, too.
   • "System (Enhanced"), which is the option I've been using for notepad++ before: The issue appears, as decribed in OP. I also have a 1920x1080 display which its scaling factor is set to 100%, and if I moved the window to my 1920x1080 display, the Document Map view returned to normal.
   • "Application": The issue does not appear. Yet the icon in the toobar does not scale to 200% in this mode. Also width the Document Map view is only half of the width in "System (Enhanced)" mode.

[Uhf7]

@gnaggnoyil Thank you for the detailed information, now I have a hint from which direction the problem comes.

There is one thing I still don't understand: Why is the transparent window able to leave the document map at all? I can simulate the effect by pretending to Notepad++ that it does not run under Windows 10. Then, the transparent window is no child window, and only then I can display it at the wrong position shown in your screen shot.

Seems as if I have to update my Windows to find out more.

[Uhf7]

Found a system with a monitor 3840 x 2160 and Windows version 1909, debug info like this:

Notepad++ v7.8.9   (32-bit)
Build time : Jul 15 2020 - 20:26:50
Path : N:\Tools\Npp\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 1909
OS Build : 18363.1016
Current ANSI codepage : 1252
Plugins : none

It is not my system, but I could use it long enough to confirm the wrong placement of the transparent part of the Document Map, when the new "System (Enhanced)" scaling mode is active. Investigating further, it turned out, that this seems to be a bug in Windows itself.

I made me a small a test program to confirm this. This test program created a transparent child window, and then switched the WS_EX_LAYERED style of this window back and forth every 3 seconds with a SetWindowLong(hWnd, GWL_EXSTYLE, ...) call.

Simultaneously, I watched the Windows messages with Spy++ and the results of GetWindowRect for my child window. The findings:

• The child window jumps to the wrong position, as soon as it is made transparent.
• The child window jumps back to the correct position, as soon as it is made opaque.
• The size of the child window is always correct.
• There are no Windows messages indicating a move or size, there are only the WM_STYLECHANG* messages and the repaint coming with it, no WM_SIZE, no WM_MOVE, no WM_WINDOWPOSCHANG*.
• GetWindowRect reports the same position, displayed wrong or not.
• Text shown in the child window is crippled (sorry, I don't have a screen shot).
• The bug does only occur in the new "System (Enhanced)" scaling mode (I used 175%).

In the moment, I'm unable to remove this effect by modifying the Notepad++ code. There were only two solutions working on this test system:

• Use another scaling mode.
• Set the compatibility settings to "Windows 8" and "System (Enhanced)" scaling mode. Then, Notepad++ falls back to the old behavior without transparent child windows and with the negative effect that the transparent part of the Document Map sometimes separates itself from the main window of Notepad++.

[gnaggnoyil]

@Uhf7 Thanks for your detailed explaination! Confirmed setting windows 8 compatibility acts as a working workaround.