fix #13

[joeskeen]

See #13 for details of the problem and the troubleshooting steps I took to arrive at this solution.

• Updated Electron to latest
• Move code that queries video sources into the main thread
• Created a backup method for identifying video source if the display_id doesn't match
• Update video source on "move" event of capture window ("moved" wasn't being called in my environment)

This pull request is a draft until I can test on all platforms:

• Windows
• Mac
• Linux

Testing complete; ready for review!

[mPyKen]

Thank you for the PR as well as all the investigation! Could you address these 2 items? Otherwise I will merge it and update the parts by myself!

[mPyKen]

I think calling determineScreenToCapture() frequently caused flickering on some systems which is why I moved this to the moved event. But it seems this event is not available on linux. Could you add a timer that will trigger the function like this? I think we can then get rid of the moved event altogether!

  let moveTimer = undefined;
  captureWindow.on("move", (event) => {
    clearTimeout(moveTimer);
    moveTimer = setTimeout(() => {
      checkWindowBounds(captureWindow);
      determineScreenToCapture();
    }, 100);
    updateMain(captureWindow.getPosition(), null);
  });

[joeskeen]

I like it - something like a debounce

[mPyKen]

I think it would be nice if we moved this condition to determineScreenToCapture() since the query for available sources has moved there

[mPyKen]

Also, I am wondering about the display_id property that don't match - does that happen only on your linux machine or on all machines? I tested this on my local (Manjaro Linux) machine and it found the display_id correctly. I wonder if this is hardware (monitor) related or software related

[joeskeen]

Another thing I noticed today when trying to use this version - at least in Linux Mint the capture window seems to capture the mouse click events, and you can't click or drag through the capture window. I'll want to look into fixing this as well.

[joeskeen]

sorry about the close and re-open - 3-year-old wanted to push buttons on my keyboard 🤦

[mPyKen]

Also, I am wondering about the display_id property that don't match - does that happen only on your linux machine or on all machines? I tested this on my local (Manjaro Linux) machine and it found the display_id correctly. I wonder if this is hardware (monitor) related or software related

I am using i3, I can confirm clicking through does not really work. It seems to be alternating between letting mouse events through and not. These logs from xev are being repeated:

...
LeaveNotify event, serial 34, synthetic NO, window 0x7600001,
    root 0x1f4, subw 0x0, time 109828541, (41,519), root:(901,540),
    mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
    focus NO, state 16

EnterNotify event, serial 34, synthetic NO, window 0x7600001,
    root 0x1f4, subw 0x0, time 109828550, (10,522), root:(870,543),
    mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
    focus NO, state 16

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys:  244 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
...

whereas it should get MotionNotify events if not trying to go through the capture window:

...
MotionNotify event, serial 34, synthetic NO, window 0x3000001,
    root 0x1f4, subw 0x0, time 109966947, (297,651), root:(1157,672),
    state 0x10, is_hint 0, same_screen YES
...