| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
enum CapturerType {
// No frames will be supplied unless CaptureFrame() is called. The caller may
// want to call CaptureFrame() at a constant rate.
kPolling,
// Frames will be supplied after Start() is called as long as the desktop
// changes. CaptureFrame() is a no-op.
kEventDriven,
};
I was thinking about this last night before I was removed from the review list so I wanted to add a comment to consider. It's true that the capturer will either poll or be event driven for Linux but it's possible to have a mixed capturer (for instance, WGC supports event driven capture if we decided to use it though we'd likely still need a fallback for GDI for secure desktops.
I'm wondering if it would be more efficient to have the network process set a capture target rate when creating the capturer and then simplify the IPC interface so that the way in which frame capture is implemented is encapsulated in the desktop process and not partially driven in the network process.
WDYT?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
enum CapturerType {
// No frames will be supplied unless CaptureFrame() is called. The caller may
// want to call CaptureFrame() at a constant rate.
kPolling,
// Frames will be supplied after Start() is called as long as the desktop
// changes. CaptureFrame() is a no-op.
kEventDriven,
};
I was thinking about this last night before I was removed from the review list so I wanted to add a comment to consider. It's true that the capturer will either poll or be event driven for Linux but it's possible to have a mixed capturer (for instance, WGC supports event driven capture if we decided to use it though we'd likely still need a fallback for GDI for secure desktops.
I'm wondering if it would be more efficient to have the network process set a capture target rate when creating the capturer and then simplify the IPC interface so that the way in which frame capture is implemented is encapsulated in the desktop process and not partially driven in the network process.
WDYT?
I decided to split up this CL after I sent it for review. Should have done this before sending out. Sorry for the churn!
I'm wondering if it would be more efficient to have the network process set a capture target rate when creating the capturer and then simplify the IPC interface so that the way in which frame capture is implemented is encapsulated in the desktop process and not partially driven in the network process.
I think this makes sense, and it is similar to what I did in [WebrtcMouseCursorMonitorAdaptor](https://source.chromium.org/chromium/chromium/src/+/main:remoting/host/webrtc_mouse_cursor_monitor_adaptor.cc). The only problem is that I'll need to move the frame scheduler from [WebrtcVideoStream](https://source.chromium.org/chromium/chromium/src/+/main:remoting/protocol/webrtc_video_stream.cc;l=127;drc=ad16e35b63a26d9c840e5ac60bdfec17deb8d011) into `DesktopCapturerWrapper` or individual capturers, but chromotocol does its own thing with frame scheduling ([cs](https://source.chromium.org/chromium/chromium/src/+/main:remoting/protocol/video_frame_pump.cc;l=55;drc=71e98710db31f5ee4c666eccd09fe14ff27514e7)). The chromotocol code is scheduled to be deleted in the next few months, so it's not like I can't break it. I'll need to think about how to do it cleanly, at least without breaking the tests though.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |