Opened 20 months ago

Last modified 20 months ago

#15072 accepted defect

Artifacts remain on screen after making app active (OSX)

Reported by: paulclinger Owned by: csomor
Priority: normal Milestone:
Component: wxAui Version: stable-latest
Keywords: Cc: csomor
Blocked By: Blocking:
Patch: no

Description

After switching to the app from other applications, there are some artifacts that are redrawn incorrectly on the screen. It doesn't happen all the time, but quite frequently. The artifacts can be seen in the attached screenshot. It's always the combobox and the scroll bar from wxTreeCtrl. After redrawing the correct screen is restored. All the components on the screen (except the toolbar) are managed by wxAuiManager.

The issue only appears on OSX (I haven't seen it on Windows).

Attachments (3)

artifacts-on-screen-after-app-activate-small.png download (139.6 KB) - added by paulclinger 20 months ago.
Shows artifacts on the screen after switching to the app
defect-cursor-295.png download (67.9 KB) - added by paulclinger 20 months ago.
defect-cursor-hint-295.png download (70.6 KB) - added by paulclinger 20 months ago.

Download all attachments as: .zip

Change History (19)

Changed 20 months ago by paulclinger

Shows artifacts on the screen after switching to the app

comment:1 Changed 20 months ago by paulclinger

Forcing a redraw on the tree control when the app is activated (wxEVT_ACTIVATE_APP) makes things worse: the entire wxTreeCtrl content is being redrawn in the wrong location (where only the scrollbar can be seen on the attached screenshot). Redrawing the editor (even with Redraw(true)) doesn't remove the artifacts.

comment:2 Changed 20 months ago by paulclinger

It appears that the pane managed by wxAuiManager is being drawn in the wrong location (shifted to the right by its width). The effect disappears if the pane is moved to the right side of the notebook.

comment:3 Changed 20 months ago by paulclinger

I got bit more information on this. I still can't reproduce the artifacts reliably, but I can reproduce the cursor changing shape as if it's over wxTreeCtrl.

As you can see on the attached screenshots, the cursor takes <|> shape at the exact position where the draggable separator would be. You can also see the hint shown at the wrong location.

The cursor seems to behave as if it's over the wxTreeCtrl, even though it's over the editor.

I don't even need to do anything to reproduce. When I just open my application, the cursor over the editor component looks correct, but it behaves as it's quickly flipping between being correct and being pointer or <|> shape when it's moved. After I move it to the wxTreeCtrl area and back, it changes the shape to the wrong one and doesn't change it back to the vertical line that is usually shown over wxStyledTextCtrl anymore.

I have a version from Feb 21st that doesn't show these symptoms, but I haven't had a chance to bisect it yet. All this is only on OSX.

Changed 20 months ago by paulclinger

Changed 20 months ago by paulclinger

comment:4 Changed 20 months ago by csomor

  • Cc csomor added

comment:5 Changed 20 months ago by paulclinger

ok, I bisected this issue to this commit -- https://github.com/wxWidgets/wxWidgets/commit/094fa9e9ef74842c293baf5e2596e1db173ac2c8 -- that fixed defect #15044. Without this commit the cursor has the right shape, but with it, it shows all the symptoms I described in comment#3.

Stefan, I don't understand all the logic, so can't really suggest what may be wrong, but is it possible that there are too many coordinate conversions in the new SetupCoordinates method? Esentially, one controls seems to 'think' that the cursor is over it (and change its shape accordingly) even when it's not the case.

I understand that it may be tricky to check if the issue is fixed, but I have everything set up and will gladly test any patch you may provide. The test only take 15m or so; you can find me as paulk in #wxwidgets.

comment:6 follow-up: Changed 20 months ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

Paul, I'll try to find out what goes wrong, but I think that from your reports - there are two different issues here, one is the wrong cursor (which most probably is linked to my 'fix') and the other one are the remnants of the combobox etc. I think the latter is not related to the cursor issues, but we need a reproducible case here. I'll try to reproduce the cursor problem first, and come back

comment:7 Changed 20 months ago by SC

(In [73636]) trying to solve cursor update problems with AUI, refs #15072

comment:8 in reply to: ↑ 6 Changed 20 months ago by paulclinger

Hi Stefan,

Replying to csomor:

Paul, I'll try to find out what goes wrong, but I think that from your reports - there are two different issues here, one is the wrong cursor (which most probably is linked to my 'fix') and the other one are the remnants of the combobox etc. I think the latter is not related to the cursor issues, but we need a reproducible case here. I'll try to reproduce the cursor problem first, and come back

You are absolutely right about two issues; I was just glad that I found this problem with the cursor as I was hoping it could help you figure out what happens with the redrawing issue, which I couldn't reliably reproduce.

I can report that your last patch fixed the cursor issue and also didn't break #15044, so it's all good. However, there is still something wrong in terms of coordinates, as I can see that the hint you can see in the second screenshot I posted (defect-cursor-hint-295.png) is still there. Any idea what may be causing this?

comment:9 Changed 20 months ago by csomor

I see one possible issue, I'm getting the moved event for the entire hierarchy, not only for the deepest child in the hierarchy, I'll check

comment:10 Changed 20 months ago by SC

(In [73637]) avoid multiple mouse moved events, refs #15072

comment:11 Changed 20 months ago by paulclinger

Hi Stefan, thank you for taking another shot at fixing this. I tested the updated version (the one that includes [73637]) and while there was some progress, the hint is still there. Before the last change I could see a quick "struggle" when the mouse is moved between the vertical-bar editor cursor and the tree-control cursor (with the editor cursor winning). I don't see that "struggle" anymore, so it all looks clean, but the hint is still shown.

It looks like this: I move the mouse to the tree control over some item that is longer than the control width. If I then move to the editor area, the hint will appear after a short interval. The cursor can be anywhere over the editor at this point.

comment:12 Changed 20 months ago by csomor

Hi Paul, yes, I've seen this too, I'm looking at the tooltips code now, seems some calls are not issued from the NSToolTipManager.

comment:13 Changed 20 months ago by SC

(In [73641]) supporting also mouse entered / exited events which are not sent to the deepest child window, refs #15072

comment:14 Changed 20 months ago by paulclinger

Thanks Stefan! All seems to work so far (no hint and the cursor is of the right shape). I'll let you know if I see the artifacts. Thank you for the quick fix.

comment:15 Changed 20 months ago by csomor

Thanks for the testing, the solution I've adopted is not as precise as I want to, I may be suppressing too much, I'll do some further tests

comment:16 Changed 20 months ago by SC

(In [73642]) more specific solution to tooltips appearing on neighboring views, refs #15072

Note: See TracTickets for help on using tickets.