Win10 update to version Creator

[.Paul.]

Originally Posted by transmitterdan

Paul,

This is good information. It helps identify the conditions. I think it still has to do with the event queue getting flooded. I think navigate to hear causes a stream of events to be created providing XTE information.

Here is a screenshot. Checkmarks for Serial and Network "Connections" were removed before this run. "Navigate to Here" activated. "Close" activated from "X" in top-right corner. Chart Canvas has diagonal hatching, but OpenCPN is not closing. Task Manager (with "Always on top" Option) shows CPU, Memory, Disk and Network usage with the totals for the computer on the column headings and for the Chart Plotter and Navigator (OpenCPN) on the highlighted line.



The CPU seems to be lightly loaded.

I used Alt to display the Menu bar, and a second Alt closed the program.

Paul

[transmitterdan]

Originally Posted by CarCode

You might want to read the sources a little bit. This code change is part of the function "MyApp::OnExit()" and therefor seems to be the reason for the hang. In no way "It just uninstalls the crash reporter program before installing a new version."

Gerhard

Gerhard,

I looked at the code in question. When O does not close it never reaches the function MyApp::OnExit(). If it ever does get to that function it always closes quickly.

It seems something is posting lots of events to the app event queue. The OnCloseWindow() function in chart1.cpp wants the event queue to empty because it would like to save the last known ship's coordinate and make sure the display is updated before closing down the window. But for some users the event queue never gets empty. There is always another event to process thus the call to Yield() does not return. That prevents the program feom ever reaching OnExit().

[bdbcat]

Dan...

Reading the code again....

The last wxYield() call is there to allow the last screen repaint to occur, which gives us the useful diagonal hash overlay, and a possible text message in OpenGL mode.

But actually, in modern wxWidgets, the sequence:

   cc1->Refresh( true );
    cc1->Update();

gives us the same effect, without involving the message queue. The screen repaint is done inline, and will definitely return.

So, bottom line, it seems safe to simply delete the offending wxYield() call at this point, and let the chips fall where they may.

Would doing this resolve the issue for your specific reproducible configuration?

Dave

[transmitterdan]

Dave,

I will test with your suggestion.

I have a branch (ShutdownFix) in my fork that closes properly in my test scenario whereas the master branch does not. I did not remove the Yield() calls.

[transmitterdan]

Dave,

In all test cases O closes with the wxYield() at line 3457 of chart1.cpp commented out. It would not close in my test cases with that line active.

I also see briefly the hatched chart viewport so that is working as you described.

I think this is the best fix.

Dan

[.Paul.]

Originally Posted by bdbcat

Dan...

Reading the code again....

The last wxYield() call is there to allow the last screen repaint to occur, which gives us the useful diagonal hash overlay, and a possible text message in OpenGL mode.

But actually, in modern wxWidgets, the sequence:

   cc1->Refresh( true );
    cc1->Update();

gives us the same effect, without involving the message queue. The screen repaint is done inline, and will definitely return.

So, bottom line, it seems safe to simply delete the offending wxYield() call at this point, and let the chips fall where they may.

Would doing this resolve the issue for your specific reproducible configuration?

Dave

Dave, Dan,

I just changed the "wxYield()" at line 3457 of chart1.cpp to a comment in my clone of the source and built the setup package for Windows. Installed same.

I have tested the cases that I listed in previous posts to this thread where OpenCPN under Win 10 Creators Update would not Close. All of these cases Close using the usual "click on X in the top left corner".

There is a slight delay of one or two seconds with the spinning disk after clicking on the "X" before the diagonal hatching appears and the window closes. Sometimes I did not see the hatching.

Paul

[bdbcat]

Paul...

Thanks for the report. I think we are getting a handle on this one.

The hash screen will not last long unless the background threads doing raster chart compression/caching are busy, and take some time to settle down. On a mature system, this will be rare.

Theoretically, we could move the screen update for the hashes earlier, so that there is immediate feedback to the user that "Close" has started. Might be worth some experimentation.

Dave

[.Paul.]

Originally Posted by bdbcat

Paul...

...

Theoretically, we could move the screen update for the hashes earlier, so that there is immediate feedback to the user that "Close" has started. Might be worth some experimentation.

Dave

I think it is good enough as is (with the one "wxYield()" removed). The busy cursor is enough feedback.

Paul

[transmitterdan]

Originally Posted by .Paul.

I think it is good enough as is (with the one "wxYield()" removed). The busy cursor is enough feedback.

Paul

I agree with Paul. There is enough feedback. Deleting the call to wxYield() is a good solution.

But i predict this issue will arise again someday. I don't like not understanding the root cause. Something is putting events into the queue such that it never empties for some users but obviously not others. It seems to be related to NMEA mux and/or OpenGL on Windows 10 with recent updates.

I am beginning to wonder it it is some kind of hard to trigger bug in wx 3.0.

[Group9]

Has there ever been a Windows update that actually made your computer run better? I can't recall one.

[CarCode]

Originally Posted by Group9

Has there ever been a Windows update that actually made your computer run better? I can't recall one.

But you might recall it is always getting more and more worse...

It seems to be the destiny of any software. Even Mac OSX has seen better days and sadly OpenCPN takes the same way.

Gerhard

[Hakan]

My view:
Win10 is better and better, soon comparable to XP, and update to Creator is working great on my dated HP. O is opened faster then ever and closing slightly faster than before!
OpenCPN is really better and better, where possible, and is still the best navigation program available for PC and Android.

And the community represented on this forum is so great taking care of every problem coming up. Mostly in a friendly manner and all can contribute and are welcome whatever manner showing up. (Hopefully also my weird English? )

Thanks all/ Håkan

[Group9]

Originally Posted by CarCode

But you might recall it is always getting more and more worse...

It seems to be the destiny of any software. Even Mac OSX has seen better days and sadly OpenCPN takes the same way.

Gerhard

My Windows computer and my Apple Ipad, both run slower after every update. I just fear the update that finally makes them stop all together.