The browser window fails to populate and the program freezes. A "confirm" window was noted in Task Manager at one point (though it wasn't visible); could that have something to do with it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ISTM that Windows is not displaying a modal dialog box when in full screen mode. Modal dialog boxes will block the the program until the dialog is acknowledged. They're supposed to always be shown on top.
Further investigation required.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK - I've been able to reproduce this one. I don't believe it is related to the ticket reported by Tom, as I was unable to reproduce his issue. Also note that the issue doesn't occur on Linux. Will check whether this happen on Mac, as I'll do a build today.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked - this problem has been present since 3.2.0-alpha.3 release, which is the earliest 3.2 release on FRS. It is not present in 3.1.0 release. This narrows the range a bit, but its going to take some time to narrow it down further, as most likely, alpha.3 was the first successful Windows build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interestingly, I succeeded in building 3.2.0-alpha.1 for Windows, with a need to copy the most recent node_api.cc shim. More interestingly, when first starting Minsky, then main window freezes in exactly the same way as soon as you move it. That means that the problem on the main window was fixed between alpha.1 and alpha.3 - if we can narrow down what the fix was, then it might be a matter of applying it to the variable pane.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And the main window freeze if fixed in alpha.2, but obviously the variable browser freeze is still present. Will look at what changed between alpha.1 and alpha.2 for clues tomorrow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good news! There were not many changes in that range, and quickly tracked it down to a single line which had the clue. For completely undocumented reasons, the renderFrame call, which sets up the cairo canvas for rendering too needs to be called synchronously on Node's thread, after which the actual drawning can be done asynchronously (on Macs it has to be synchronous drawing as well, at a noticeable performance hit). I implemented the switch to synchronous processing in the backend addon code, so that we don't need to think about it in the frontend typescript code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The browser window fails to populate and the program freezes. A "confirm" window was noted in Task Manager at one point (though it wasn't visible); could that have something to do with it?
Just tried after a reboot. Obviously one to fix on Tuesday, if you can find it.
Could be the same as https://sourceforge.net/p/minsky/ravel/403/
ISTM that Windows is not displaying a modal dialog box when in full screen mode. Modal dialog boxes will block the the program until the dialog is acknowledged. They're supposed to always be shown on top.
Further investigation required.
OK - I've been able to reproduce this one. I don't believe it is related to the ticket reported by Tom, as I was unable to reproduce his issue. Also note that the issue doesn't occur on Linux. Will check whether this happen on Mac, as I'll do a build today.
I have checked - this problem has been present since 3.2.0-alpha.3 release, which is the earliest 3.2 release on FRS. It is not present in 3.1.0 release. This narrows the range a bit, but its going to take some time to narrow it down further, as most likely, alpha.3 was the first successful Windows build.
Interestingly, I succeeded in building 3.2.0-alpha.1 for Windows, with a need to copy the most recent node_api.cc shim. More interestingly, when first starting Minsky, then main window freezes in exactly the same way as soon as you move it. That means that the problem on the main window was fixed between alpha.1 and alpha.3 - if we can narrow down what the fix was, then it might be a matter of applying it to the variable pane.
And the main window freeze if fixed in alpha.2, but obviously the variable browser freeze is still present. Will look at what changed between alpha.1 and alpha.2 for clues tomorrow.
Whew! Good to hear (sort of--what contortions operating systems impose upon
you!).
Good news! There were not many changes in that range, and quickly tracked it down to a single line which had the clue. For completely undocumented reasons, the renderFrame call, which sets up the cairo canvas for rendering too needs to be called synchronously on Node's thread, after which the actual drawning can be done asynchronously (on Macs it has to be synchronous drawing as well, at a noticeable performance hit). I implemented the switch to synchronous processing in the backend addon code, so that we don't need to think about it in the frontend typescript code.