wrong xor line is drawn when I drag the wxSplitterWindow' sash bar with wxSP_LIVE_UPDATE disabled

[asmwarrior]

Hi, it looks like this bug happens for a long time, it exists in wx 3.1.0 release and 3.1.1-rc.

I build the sample code: wxWidgets-3.1.1-rc\samples\splitter\splitter.cpp, but I have comment out this option "wxSP_LIVE_UPDATE" around line 505

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

Now, with wxSP_LIVE_UPDATE option disabled, it is expect to show a XOR line when I drag the sash bar, but I see the XOR line is drawn in the wrong place, see the screen shot as attachment.

My build environment is: Windows 7 64bit system. wx3.1.1-rc or wx3.1.0, the compiler is mingw-w64 mingw-build 32bit gcc 7.2 or 32bit gcc 5.4.

Any ideas?

BTW: I first report this issue in the wx forum, see here: When drag the sash line of wxSplitterWindow, the target line has offset - https://forums.wxwidgets.org/viewtopic.php?f=1&t=44307

Thanks.

Asmwarrior

[asmwarrior]

OK, I test another simple splitter window sample code(which from: https://wiki.wxwidgets.org/WxSplitterWindow, the first sample code), and I use the PickPick to catch the screen shot, it looks like the left and right control has the *wrong* position, see the 2 image shots, and this is the reason why the XOR line is drawn on the wrong place.

Any ideas?

Thanks.

Asmwarrior

[Vadim Zeitlin]

On Sat, 24 Feb 2018 09:45:32 +0800 asmwarrior wrote:

a> Hi, it looks like this bug happens for a long time, it exists in wx
a> 3.1.0 release and 3.1.1-rc.
a>
a> I build the sample code:
a> wxWidgets-3.1.1-rc\samples\splitter\splitter.cpp, but I have comment out
a> this option "wxSP_LIVE_UPDATE" around line 505
a>
a> MySplitterWindow::MySplitterWindow(wxFrame *parent)
a> : wxSplitterWindow(parent, wxID_ANY,
a> wxDefaultPosition, wxDefaultSize,
a> wxSP_3D | /* wxSP_LIVE_UPDATE |*/
a> wxCLIP_CHILDREN /* | wxSP_NO_XP_THEME */ )

You don't really need to do this, the sample has "Toggle live update" menu
item in its menu which allows to change this while running it.

a> Now, with wxSP_LIVE_UPDATE option disabled, it is expect to show a XOR
a> line when I drag the sash bar, but I see the XOR line is drawn in the
a> wrong place, see the screen shot as attachment.

Very strange, I don't see this at all (I even made the change above to be
sure). I've only tested this in MSVC build so far, but I don't see why
would it be different for MinGW.

a> Any ideas?

Not really, sorry. This needs to be debugged, but I know that debugging
with gdb under MSW is painful (personally I use remote gdb under Linux to
do it...).

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[asmwarrior]

Hi, VZ, thanks for the reply. The bug is located(with the help of doublemax from wx forum), see this post.
Re: When drag the sash line of wxSplitterWindow, the target line has offset - https://forums.wxwidgets.org/viewtopic.php?p=182214#p182213
In short, the option "Enable Desktop composition" is the reason. I will report this issue to wx's ticket system.


Asmwarrior

[Vadim Zeitlin]

On Sat, 24 Feb 2018 21:33:31 +0800 asmwarrior wrote:

a> In short, the option "Enable Desktop composition" is the reason.

Sorry, what option is this and where can it be found?

[asmwarrior]

On 2018/2/24 PM9:37, Vadim Zeitlin wrote:
> On Sat, 24 Feb 2018 21:33:31 +0800 asmwarrior wrote:
>
> a> In short, the option "Enable Desktop composition" is the reason.
>
> Sorry, what option is this and where can it be found?
> VZ
>

It is a setting of Windows system. In this post: Re: When drag the sash line of wxSplitterWindow, the target line has offset - https://forums.wxwidgets.org/viewtopic.php?p=182214#p182212 doublemax described the steps to disable it:

"Enable Desktop composition" in the performance options of Windows system setting.

I have confirmed that enabling this option will cause my reported issue, but if this option is turn off, then the issue is gone. I have also use the GDB to debug this issue a while, the analysis is posted here: Re: When drag the sash line of wxSplitterWindow, the target line has offset - https://forums.wxwidgets.org/viewtopic.php?p=182214#p182213


Asmwarrior

[Vadim Zeitlin]

On Sat, 24 Feb 2018 21:51:03 +0800 asmwarrior wrote:

a> On 2018/2/24 PM9:37, Vadim Zeitlin wrote:

a> > On Sat, 24 Feb 2018 21:33:31 +0800 asmwarrior wrote:
a> >

a> > a> In short, the option "Enable Desktop composition" is the reason.
a> >
a> > Sorry, what option is this and where can it be found?
a> > VZ
a> >
a>
a> It is a setting of Windows system. In this post: Re: When drag the sash
a> line of wxSplitterWindow, the target line has offset -
a> https://forums.wxwidgets.org/viewtopic.php?p=182214#p182212 doublemax
a> described the steps to disable it:
a>
a> "Enable Desktop composition" in the performance options of Windows
a> system setting.

If it's the standard Windows option enabling Aero, then it's definitely
enabled for me (as is the case by default) -- yet I still don't see the
bug.

a> I have confirmed that enabling this option will cause my reported issue,

I wonder why was it disabled in the first place...

a> but if this option is turn off, then the issue is gone. I have also use
a> the GDB to debug this issue a while, the analysis is posted here: Re:
a> When drag the sash line of wxSplitterWindow, the target line has offset
a> - https://forums.wxwidgets.org/viewtopic.php?p=182214#p182213

Sorry, I really have no idea why is it called with the wrong size the
second time.

Regards,

[asmwarrior]

Hi, VZ, I checked the samples\splitter\splitter.cpp code again.
In my system:

If "Enable Desktop composition" is check on. (This is the default setting of my computer)
step 1: Running the built executable, and drag the split bar, no issue here(because Live update is on)
step 2: Click the menu item "Live update" to off status, then drag the split bar, this issue happens.

If "Enable Desktop composition" is check off.
step 1: Running the built executable, and drag the split bar, no issue happens.
step 2: Click the menu item "Live update" to off status, then drag the split bar, no issue happens.

I really don't know why.It looks like this issue only happens on a wx3.x based application, because my Code::Blocks IDE(which is wx 2.8.12 based) won't have such issue.

Asmwarrior

[asmwarrior]

I have create a ticket here:

#18090 (wrong xor line is drawn when I drag the wxSplitterWindow' sash bar with wxSP_LIVE_UPDATE disabled) – wxWidgets -
https://trac.wxwidgets.org/ticket/18090#ticket

The ticket mention both the wx mailist discussion and the wx forum thread.

Thanks.
Asmwarrior

[Gunter Königsmann]

If the compositor is enabled every application has its own location in
the computer's memory it can draw its window contents into. The graphics
hardware (with help from the graphics driver) then determines which
pixel to take from where.

Compositing also allows the cool visual effects Vista comes from
(blurring, fast zoom, wobbly windows and fire).

It further allows to compose the graphics of several layers: The window
contents, above it a layer with the half-transparent rectangle for the
selected text above which a layer for moving objects like splitters can
be placed. The advantage is that the splitter can be drawn by the
graphics accellerator and if one wants to show the pixel below the
splitter it suffices to set the splitter's pixel to "transparent".

If the problem is only present when compositing (and thus all kinds of
acceleration and off-loading drawing things to the GPU) is enabled and
if it doesn't happen on every computer I would guess that the bug lies
somewhere in the graphics driver.

Kind regards,

Gunter.

[Eric Jensen]

Hello Vadim,

Saturday, February 24, 2018, 2:56:46 PM, you wrote:

a>> "Enable Desktop composition" in the performance options of Windows
a>> system setting.

VZ> If it's the standard Windows option enabling Aero, then it's definitely
VZ> enabled for me (as is the case by default) -- yet I still don't see the
VZ> bug.

It's related to HiDPI. It happens if the magnification is set to 150%
and the application is not marked as DPI aware.

wxSplitterWindow::DrawSashTracker() uses wxScreenDC to write directly
onto the screen. Either that fails or the conversion of the
coordinates using ClientToScreen().

Hth,
Eric





--

[Vadim Zeitlin]

On Sat, 24 Feb 2018 20:03:38 +0100 Eric Jensen wrote:

EJ> Saturday, February 24, 2018, 2:56:46 PM, you wrote:
EJ>
EJ> a>> "Enable Desktop composition" in the performance options of Windows
EJ> a>> system setting.
EJ>
EJ> VZ> If it's the standard Windows option enabling Aero, then it's definitely
EJ> VZ> enabled for me (as is the case by default) -- yet I still don't see the
EJ> VZ> bug.
EJ>
EJ> It's related to HiDPI. It happens if the magnification is set to 150%
EJ> and the application is not marked as DPI aware.

Ah, thanks for the idea. To the OP: could you please confirm that your
system uses high DPI?

[asmwarrior]

On 2018/2/25 上午6:46, Vadim Zeitlin wrote:
> On Sat, 24 Feb 2018 20:03:38 +0100 Eric Jensen wrote:
>
> EJ> Saturday, February 24, 2018, 2:56:46 PM, you wrote:
> EJ>
> EJ> a>> "Enable Desktop composition" in the performance options of Windows
> EJ> a>> system setting.
> EJ>
> EJ> VZ> If it's the standard Windows option enabling Aero, then it's definitely
> EJ> VZ> enabled for me (as is the case by default) -- yet I still don't see the
> EJ> VZ> bug.
> EJ>
> EJ> It's related to HiDPI. It happens if the magnification is set to 150%
> EJ> and the application is not marked as DPI aware.
>
> Ah, thanks for the idea. To the OP: could you please confirm that your
> system uses high DPI?
>
> Regards,
> VZ
>

Hi, VZ, 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/windows-and-office/get-a-better-view-in-windows-7-by-adjusting-dpi-scaling/)

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

@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?

Thanks Eric for the help!

Asmwarrior