Strange Occasional loss of mouse input

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Strange Occasional loss of mouse input

Post by mbeardsley »

I have an unusual bug which appears quite rarely, and I am curious if anyone has seen something similar.
This is using wxWidgets 3.0.2 on Windows 7 (VisualStudio 2010)

Once in a while, it seems like my application stops registering mouse click input (both left and right buttons).

When this occurs, it has the following symptoms:
- The app is still running, as I can see it constantly updating my OGL canvas.
- All wxWidgets no longer respond to any mouse clicks
- Even the OS-level functions (such as moving/re-sizing the frame) do not work.
- Clicking the X button to close the frame does not work either (nor does minimizing/maximizing the frame)
- The app CAN be closed by right-clicking on the program's icon in the task bar
- The mouse works fine with other applications (both mine and 3rd party apps)
- It is NOT specific to a particular machine or mouse (I have seen it occur on three different machines)
- It SEEMS to only occur after the app has been running for a few hours (but the app can also run for days without it occurring)
- I have never seen it happen in debug mode, though the app is usually run in release (so this may not mean much)
- I have not found a way to reproduce the issue (it seems to occur "once in a while, for no obvious reason")

It seems like wxWidgets (or something) is not only ignoring the mouse click events, but not even passing them on to Windows.

Has anyone seen behavior like this before?
If a wxMouseEvent is captured (and event.Skip() is not called) could this prevent Windows from seeing/processing the mouse click?

I'd be thankful for any insight here.
User avatar
doublemax
Moderator
Moderator
Posts: 19115
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Strange Occasional loss of mouse input

Post by doublemax »

When even moving the frame doesn't work, the event loop is not processing any events.

Possible causes:
- 100% CPU load, e.g. when rendering is too slow and you're generating paint events faster than they can be processed

- you're sending custom events to the main thread at a higher rate than events can be processed

- you catch a paint event but do not create a wxPaintDC in the paint event handler (under Windows you *must* create one, even if you don't use it, e.g. when you're using OpenGL commands only)
If a wxMouseEvent is captured (and event.Skip() is not called) could this prevent Windows from seeing/processing the mouse click?
Yes. And if you capture the mouse, you *must* handle the wxMouseCaptureLostEvent.
Use the source, Luke!
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Re: Strange Occasional loss of mouse input

Post by mbeardsley »

Thanks for the fast response!

To address your suggestions:
- I don't believe it is a CPU/Rendering load, as over the weekend it occurred again (on a very high-end machine) when it was only rendering a small amount of text (the CPU load is usually around 1%).
- In this particular app, I don't have any custom events.
- I do catch the Paint event, and I do create a wxPaintDC instance (even though it is not being used).

I probably mis-phrased my question regarding "capturing". I do not use CaptureMouse() in this application.
I simply catch the wxEVT_LEFT_DOWN, wxEVT_MOTION, and wxEVT_LEAVE_WINDOW events. The handlers for these events did NOT end with an event.Skip() (and there are no "higher" level windows expecting these events - other than MSWindows itself).

I have now added a Skip() call to each of these, though I probably won't know for a long time whether this has helped or not (the bug only appears once every few weeks).

As a further bit of info (that may or may not be relevant), this app is a bit different than several of my other OGL/wxWidget apps, in that it has a (main) frame that consists solely of an OGL canvas, and then two other child frames that have only standard wxWidget controls in them.

Thanks again for any input.
User avatar
doublemax
Moderator
Moderator
Posts: 19115
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Strange Occasional loss of mouse input

Post by doublemax »

I probably mis-phrased my question regarding "capturing". I do not use CaptureMouse() in this application.
I simply catch the wxEVT_LEFT_DOWN, wxEVT_MOTION, and wxEVT_LEAVE_WINDOW events. The handlers for these events did NOT end with an event.Skip() (and there are no "higher" level windows expecting these events - other than MSWindows itself).
In this case a missing Skip() can not explain the error. You should probably remove the added Skip() calls again.
I have now added a Skip() call to each of these, though I probably won't know for a long time whether this has helped or not (the bug only appears once every few weeks).
Does it only happen when the application is running for a very long time? If yes, check the GDI and USER handles using the Windows task manager. Maybe there is a handle leak somewhere.

If that's not it, i'm out of ideas.
Use the source, Luke!
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Re: Strange Occasional loss of mouse input

Post by mbeardsley »

It SEEMS as if it takes a while (at least a few hours) before this happens, but it happens so infrequently that it is hard to say anything for sure.

Several times I have gone back into the lab where it is running and found it in this state, but not really knowing how long it has been that way. Only one time as anyone seen it happen "live", and he wasn't doing anything unusual at the time (and he has not been able to make it happen again).

Other times it has run the whole weekend and still been fine.

I'm assuming that it is a bug somewhere in my code, I was just hoping someone would have seen something like this before and say "Oh, yeah, that happens if you do X without doing Y."

I will keep an eye on the handles and see if I notice anything suspicious.

Thanks for your help, they were good suggestions.
User avatar
marcelinux
Knows some wx things
Knows some wx things
Posts: 40
Joined: Thu Nov 07, 2013 9:59 pm
Location: Madrid, Spain

Re: Strange Occasional loss of mouse input

Post by marcelinux »

Meanwhile, you could... use a log?
Good luck.
I just need learn a little bit more. Thank you for your help.
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Re: Strange Occasional loss of mouse input

Post by mbeardsley »

I'm not sure what you mean...what information do you suggest that I log?
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Re: Strange Occasional loss of mouse input

Post by mbeardsley »

In looking over some other posts about event handling, I'm wondering if I might be having an issue with my timer-based rendering loop.

Doublemax, you mentioned that if the timer events were happening too fast this could be a problem. Other posts have alluded to having events "backed-up".

What COULD be happening is that my timer event is triggering at 15.625ms (essentially 64hz), but the video card may be limiting my rendering loop to 60hz. If so, there might be a slow "build-up" of timer events.

Is there some way that I can detect if there are additional "pending" timer events (and if so, see if this number is slowly increasing) ?

If I could detect pending timer events, I could probably skip the current timer event (processing only the "most-recent" event) to prevent any event back-up.

Thanks.
User avatar
doublemax
Moderator
Moderator
Posts: 19115
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Strange Occasional loss of mouse input

Post by doublemax »

What COULD be happening is that my timer event is triggering at 15.625ms (essentially 64hz), but the video card may be limiting my rendering loop to 60hz. If so, there might be a slow "build-up" of timer events.
This sounds like it could be a possible explanation. As a first step i'd try to use wxStopWatch to measure how long the redraw takes. AFAIK it uses performance counters under Windows, so it doesn't suffer from the 15ms timer granularity.
Is there some way that I can detect if there are additional "pending" timer events (and if so, see if this number is slowly increasing) ?
AFAIK there is no way to check the size of Windows message queue. Its size defaults to 10000.

I would try to use the timer in one-shot mode and only start the timer again at the end of the redraw. This would make sure that the message queue is not filling up. Getting a nice refresh rate will be tricky because of the problem with the timer granularity we already discussed in another thread. Did you make any research regarding high resolution timers under Windows?

This one looks promising:
http://www.codeguru.com/cpp/g-m/multime ... Timers.htm
Use the source, Luke!
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Re: Strange Occasional loss of mouse input

Post by mbeardsley »

I will try the one-shot timer approach - I hadn't thought of that.

I did look into the timer issue a bit (using a similar approach to that one), but there is still a big resolution problem.
The timeBeginPeriod() call still has a best resolution of 1 millisecond, which means I could run either a 16ms timer or a 17ms timer.
But what I really want is a 16.667ms timer. For me, 16ms is really no better than 15.625ms.

Currently, I have two different loop mechanisms that I can switch between:
1) Run off of a (continuous) timer event loop at 64hz (15.625ms) with the video card NOT locking to v-blank (and living with potential screen-tearing issues).
2) Run off of an idle event loop with the video card locking to v-blank at 60hz (and living with the spin-wait pegging a whole core to 100% usage).

But maybe, using your one-shot timer idea, I could combine them.

If I run off of a one-shot timer in place of the idle event loop (and still locking to v-blank), I might be able to get the best of both methods. I will have to test this out.

Thanks!
mbeardsley
Experienced Solver
Experienced Solver
Posts: 74
Joined: Thu Sep 25, 2014 7:40 pm

Re: Strange Occasional loss of mouse input

Post by mbeardsley »

After some further analysis, it does seem that using a one-shot timer (repeatedly) works better than using a continuous timer (whether vsync is enabled or not).

I now re-start the one-shot timer inside my timer handler (which means that timer events cannot become "backed up" since only one timer event can be in progress at any time).

I can't be sure yet if it has really solved my original problem (though I am hopeful), but some other timing issues seem to have improved (and things seem to perform in a more consistent manner across different machines).

Thanks for the help.
Post Reply