I'm using H2R-0.4.0 to support conferences using a Jitsi-based product (Pàdé for OpenFire, https://github.com/igniterealtime/openfire-pade-plugin). Here, I use H2R's Chroma Window as a screen shared window to feed my video stream. In general, this works as expected.
I'm using Chromium@Ubuntu-20 as the local browser. It's a well-known fact, that the application window used in the browser as a source for a screen share *must be not minimized, i.e. must have a "usable" canvas.
But with H2R I made the observation, that the H2R Chroma Window must also be located on the same X11 workspace as the browser window to keep "things running". If it's moved to be completely off the current visible display area, the scheduled CPU time will be heavy cut down and e.g. the Ticker will become very stuttering.
Note, that to avoid this, it will be enough to have "just one pixel" of the Chroma Window on current displayed workspace area. It also don't have to be "visible", it might be complete covered by another maximized application window.
Therefore, as a workaround, I put it "behind" the Cromium window I use to participate the A/V conference session.
I wonder what's the core reason for this. Maybe there's a (dirty?) trick to avoid it. On most of the X11 window manager, one may "pin" an application window to be visible on all workspaces, i.e. it will "follow" if one switch around. But this seems to coupled with the "stay on top" feature and isn't usable for this reason.
I'm using H2R-0.4.0 to support conferences using a Jitsi-based product (Pàdé for OpenFire, https://github.com/igniterealtime/openfire-pade-plugin). Here, I use H2R's Chroma Window as a screen shared window to feed my video stream. In general, this works as expected.
I'm using Chromium@Ubuntu-20 as the local browser. It's a well-known fact, that the application window used in the browser as a source for a screen share *must be not minimized, i.e. must have a "usable" canvas.
But with H2R I made the observation, that the H2R Chroma Window must also be located on the same X11 workspace as the browser window to keep "things running". If it's moved to be completely off the current visible display area, the scheduled CPU time will be heavy cut down and e.g. the Ticker will become very stuttering.
Note, that to avoid this, it will be enough to have "just one pixel" of the Chroma Window on current displayed workspace area. It also don't have to be "visible", it might be complete covered by another maximized application window.
Therefore, as a workaround, I put it "behind" the Cromium window I use to participate the A/V conference session.
I wonder what's the core reason for this. Maybe there's a (dirty?) trick to avoid it. On most of the X11 window manager, one may "pin" an application window to be visible on all workspaces, i.e. it will "follow" if one switch around. But this seems to coupled with the "stay on top" feature and isn't usable for this reason.