mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 15:15:51 +03:00
[GH-ISSUE #633] Crash with new recorder UI on 3+ monitor setup. #517
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#517
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @waltdestler on GitHub (Apr 8, 2020).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/633
ScreenToGif is crashing on my computer if I try to use the new recorder UI with at least 3 monitors enabled in control panel. (By "crash" I mean that after clicking "Recorder", the startup window disappears, it thinks for a second while my mouse cursor moves very slowly, and then it silently exits without any error message.) If I disable any combination of monitors such that I have at most only 2 active, then it works fine. FWIW each of my monitors has a different DPI scaling setting, but I tried setting them all to 100% with no luck.
I also tried building from source and running with the Visual Studio debugger attached, but the same thing happens: the process simply exits without any obvious error or exception thrown. I tried manually stepping through with the
OpenRecordercommand in ApplicationViewModel.cs, but stepped through it fine; it quits someplace later that I wasn't able to determine.I'm a programmer myself and know C# very well (though I have little experience with XAML), so I'm happy to help try to debug this, I just need a tip on where in the code I should try looking for an issue.
OS: Windows 10 x64 10.0.18362
@NickeManarin commented on GitHub (Apr 9, 2020):
Hi, you can try running and crashing again, open the Event Viewer (
Windows X > Event Viewer) and check for any errors on theWindows Logs > Applicationsection.Uncaught errors should appear in there in two items on the list.
Also, it's possible that the app created some logs in the same folder as the main executable, (actually, in a folder called ScreenToGif/Logs inside the same folder of the executable).
@waltdestler commented on GitHub (Apr 9, 2020):
Nothing in ScreenToGif/Logs, but I do have a couple errors in the Windows event viewer:
@NickeManarin commented on GitHub (Apr 9, 2020):
Have you found anything else? Usually it's two entries.
Anyway, so far I found that a similar crash had a missing DLL. It could be the same case as yours:
D3DCompiler_47.dll should be in %windir%\system32
But, of course, it could be something else.
@waltdestler commented on GitHub (Apr 9, 2020):
Those are the two entries. (Added a line to separate them.)
I do have D3DCompiler_47.dll in my System32 directory. I also just tried copying it into the ScreenToGif folder alongside the exe, which didn't help.
FWIW, the same problem occurs regardless of whether I have it set to DirectX or BitBlt mode. (And works fine with the old recorder UI even in DirectX mode.)
Regardless, it seems pretty strange to me that a missing DLL would only be a problem with 3+ monitors... but I suppose you never know!
@NickeManarin commented on GitHub (Apr 9, 2020):
Ah, thought it was a single one.
I believe it's related to how the new UI operates. It works as a single, full-size transparent window that fills up the entire set of screens. I don't have three monitors so I could test (I only have two).
Anyway, if is that the case, I'm already working on a new solution that does not involve creating a massive fullsize transparent window, but I'm facing some issues working with multiple DPI right now.
It was the only crash related to
wpfgfx_v0400.dlthat I could find with a proper solution. It could be something different.@waltdestler commented on GitHub (Apr 9, 2020):
Ah, very cool! Feel free to ping me if you want me to test on my setup.
@NickeManarin commented on GitHub (Apr 10, 2020):
If you have the source there with you, you could replace the line 77 with line 78 to try opening the new version of the recorder.
https://github.com/NickeManarin/ScreenToGif/blob/master/ScreenToGif/Model/ApplicationViewModel.cs#L77
It should open normally and you should be able to select your recording region, but you won't be able to record anything, because it's not yet finished.
@waltdestler commented on GitHub (Apr 10, 2020):
It works! It opens fine, and I can select a region, though the framerate while doing so is very low (but still usable). It does not seem to remember the region I previously selected when opening it again. (Guessing that's not implemented yet either.)
@NickeManarin commented on GitHub (Apr 10, 2020):
Nice!
Is it the same slowness on all monitors? I noticed that the current version gets slow while having more than one monitor, but I could not improve much the performance.
Yeah, only the basic stuff was ported to this new version. I was working recently on the window selection when I hit a bump trying to solve the problem with multi DPI screens.
@waltdestler commented on GitHub (Apr 10, 2020):
Yes, it's slow on all monitors.
@kaestlyn commented on GitHub (Jun 11, 2020):
I just want to add that I had this same issue with 3 monitors. Soon as I disconnected one, I was able to launch the app and switch back to the classic recording UI and then reconnect the monitor and the application works as expected.
@NickeManarin commented on GitHub (Aug 16, 2020):
The recorder was fully reworked.
I also disabled by default the marching-ants animation that could cause slowdowns during the selection mode (but it can be turned back in).