When drag the sash line of wxSplitterWindow, the target line has offset

[ollydbg23]

Hi, when I run this example 1 code in the : WxSplitterWindow - WxWiki page, I see that when I use mouse to drag the sash line in horizontal direction, the target line(a hint line) has some offset to the mouse position. See the screen shot as attachment, any ideas what does this happens?

grag-sash.png (70.99 KiB) Viewed 3610 times

I'm using the wx 3.1.1-rc build with mingw-build gcc 7.2 32bit compiler (under a 64bit windows 7 system).
Thanks.

EDIT This issue also happens when I use the wx 3.1.0 which build against a mingw-build gcc 5.4 32bit compiler.

[doublemax]

Everything on the Wiki should be taken with a grain of salt, many things are heavily outdated.

Try with the "splitter" sample that comes with wxWidgets, that's the only valid point of reference.

[ollydbg23]

OK, thanks. But I think I can reproduce this bug in the "splitter" sample.

I just build the sample with this code changes:

Code: Select all

MySplitterWindow::MySplitterWindow(wxFrame *parent)
                : wxSplitterWindow(parent, wxID_ANY,
                                   wxDefaultPosition, wxDefaultSize,
                                   wxSP_3D | /* wxSP_LIVE_UPDATE |*/
                                   wxCLIP_CHILDREN /* | wxSP_NO_XP_THEME */ )

Note that I have comment out the "wxSP_LIVE_UPDATE", then I get such screen shot below:

drag-sash2.png (55.04 KiB) Viewed 3589 times

So, it XOR line's position is wrong, it should near the mouse cursor, but I do see an offset here.

[ollydbg23]

I post a thread in the wx user maillist, see here, and I see that the window position is not correct, see this post: https://groups.google.com/d/msg/wx-user ... 4n3vlfAAAJ

[doublemax]

Very strange. Even if i comment out the wxSP_LIVE_UPDATE, i don't see that problem with any wx version.

Can you test this on another PC?

[ollydbg23]

Very strange. Even if i comment out the wxSP_LIVE_UPDATE, i don't see that problem with any wx version.

Can you test this on another PC?

OK, I will try another win7 PC and report back.

Here, in my current win7(64bit) system, I see that this issue does not happens in wx 2.8.12. I can use Code::Blocks(which is wx2.8.12 based), and it has a buildin GUI designer called wxsmith. When I create a simple wxFrame which have a wxSplitterWindow, I can preview the wxFrame in the Code::Blocks, which shows correctly without this issue(The preview GUI is based on the wx2.8.12). But when I build the application(the application is build against wx3.1.0 or wx3.1.1), the built application have this issue.

[ollydbg23]

Very strange. Even if i comment out the wxSP_LIVE_UPDATE, i don't see that problem with any wx version.

Can you test this on another PC?

OK, I will try another win7 PC and report back.

OK, I just tried built application on another PC(which is Win7 64bit professional edition), and this issue does not happen there. So, what's the problem of my PC? My PC is Win7 64bit home basic edition. That's really strange.

[ollydbg23]

It looks like this is an theme issue, my PC was using Windows 7 standard theme, as you see my previous screen shots.

I just change my theme to "Windows classic", and then this issue is gone.

[doublemax]

I think the checkbox "Enable Desktop composition" in the performance options is what triggers it.

When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.

[ollydbg23]

I think the checkbox "Enable Desktop composition" in the performance options is what triggers it.

When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.

Thanks for this information.
You are correct, I just see that if the option "Enable Desktop composition" is checked on, than this issue happens. If this option is checked off, then I don't see this issue now.

BTW: I even debugged this issue for several hours, I set some breakpoint inside the src\generic\splitter.cpp. When this issue happens, I see that I get the void wxSplitterWindow::OnSize(wxSizeEvent& event) function call twice. The first time, I see a correct event.size is passed in, and the sash position is correct, but it soon get another OnSize() call which passed a litter smaller size. Thus the sash position is recalculated, and get a litter smaller. And the two splited sub windows were set the wrong position.

Hope some wx devs can handle this issue.

[doublemax]

Please add this information to your post on the mailing list and/or open a ticket for it.

[ollydbg23]

I created a ticket here: #18090 (wrong xor line is drawn when I drag the wxSplitterWindow' sash bar with wxSP_LIVE_UPDATE disabled) – wxWidgets, the ticket both mention the thread and the discussion in wx maillist.

It looks like the dev(Vadim Zeitlin) has different result as yours, in fact, he can't reproduce this issue. Since your result are:

I think the checkbox "Enable Desktop composition" in the performance options is what triggers it.

When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.

Thanks.

[doublemax]

Is it possible that you're running on a HiDPI screen, but your application is not marked as dpi-aware?

The problematic method is most likely wxSplitterWindow::DrawSashTracker(), which uses wxScreenDC to write directly onto the screen. Maybe the conversion from client coordinates to screen coordinates fails.

[ollydbg23]

Is it possible that you're running on a HiDPI screen, but your application is not marked as dpi-aware?

The problematic method is most likely wxSplitterWindow::DrawSashTracker(), which uses wxScreenDC to write directly onto the screen. Maybe the conversion from client coordinates to screen coordinates fails.

Hi, doublelmax, you are correct, I can confirm it. Thanks.

I checked my DPI settings of my computer's display, and I see it is 125%. My system is a 14 inch laptop which has 1920*1080 resolution.
(The setting in described in this page: https://www.techrepublic.com/blog/windo ... i-scaling/)

And I can confirm that if I explicitly run the executable from the command line like below, the issue is gone:

Code: Select all

@set "__COMPAT_LAYER=~ HIGHDPIAWARE" & start "" /max "mysplittertest.exe"

So, it is definitely a HiDPI issue. Any idea how to solve this? I just need to add a manifest file to the executable to tell the system that don't scale the text in the application like the command line option I used above?

[doublemax]

So, it is definitely a HiDPI issue. Any idea how to solve this? I just need to add a manifest file to the executable to tell the system that don't scale the text in the application like the command line option I used above?

If everything in your application works correctly when set to "dpi aware", that's definitely the best option.