We try our best to calculate the best area to use as a video region (see #410) but in some cases the heuristics cannot get it right without some help from the application or user: scrolling detection (#1232) uses whole lines but the right hand side of the window is often repainted with a scrollbar widget which moves out of sync with the rest of the window. We should provide a dbus control API to set exclusion zones that should never be considered for video region detection.
r13493 adds "video region exclusion zones" to the video region detection code (#904).
Example usage with an xterm running as window id 1 on DISPLAY :100:
xpra start --start=xterm :100 -d dbus,regiondetect
This sets the first 20 pixels on the left hand side as non-video:
./tests/xpra/test_apps/send_dbus_video_exclusion_zone.py 100 1 0,0,20,1000
We can verify that when a video region is detected (ie: by continuously scrolling and causing the xterm to repaint the whole window more than 10 times a second), the code will exclude this region from the video region:
$ xpra info | grep subregion window.1.video_subregion.height=299 window.1.video_subregion.in-out=(10268856, 488553) window.1.video_subregion.non-max-wait=150 window.1.video_subregion.rectangle=(20, 2, 477, 299) window.1.video_subregion.score=120 window.1.video_subregion.set-at=849 window.1.video_subregion.time=1472449967 window.1.video_subregion.width=477 window.1.video_subregion.x=20 window.1.video_subregion.y=2 window.1.video_subregion.counter=849 window.1.video_subregion.damaged=100 window.1.video_subregion.detection=True window.1.video_subregion.enabled=True window.1.video_subregion.exclusion-zones=((0, 0, 20, 1000),) window.1.video_subregion.fps=14
@calvinko: please add support for this API in your code and re-assign to afarr for testing. (the test code in r13493 should be self-explanatory)
As of r13591, we support relative coordinates using negative values. ie:
./tests/xpra/test_apps/send_dbus_video_exclusion_zone.py 100 1 -20,0,20,1000
will exclude the rightmost 20 pixels, no matter how wide the window is.
Confirmed it's working fine with the python file, and even fired up d-feet
to verify that it's definitely working via normal DBUS methods.
Here is the d-feet
syntax:
$WID, [[0,0,20,1000]]
where $WID is an int of the window you want that you can get with the listWindows()
function.
However, setting a region to the center of a window (like 500,500 - 600,600) seems to have no effect. Is that expected behavior or a bug?
Either way, it's working on the edges, so I'll pass word on to Calvin as that's our expected use case. As for this ticket, handing back to you.
However, setting a region to the center of a window (like 500,500 - 600,600) seems to have no effect. Is that expected behavior or a bug?
No effect?
Is it not recorded under video_subregion.exclusion-zones=
in xpra info?
Or is it not being honoured? (the rectangle
contains the excluded region)
Note: this only affects video regions, if the whole window is painted using a video encoding because we have not detected any video region, the exclusion zone will not be honoured as it only applies to video regions (detected or set by the API).
It is being recorded under video_subregion.exclusion-zones=
, but it is not being honored. As in, if I set it to a region where I know a video will be (YouTube?), then go and watch a video, it doesn't honor the region, and I get a video region regardless.
Sample output of my xpra info
:
window.3.video_subregion.exclusion-zones=((100, 100, 400, 400),) window.3.video_subregion.rectangle=(199, 121, 854, 480)
If I set it to a region that is along a border, it works fine and honors the region:
window.3.video_subregion.exclusion-zones=((0, 0, 500, 1000),) window.3.video_subregion.rectangle=(500, 121, 553, 480)
As to your note - that's what I thought, so I was testing using a YouTube? video.
Another note:
Is there a "proper" way to clear the region exclusion? I know I can just set it to [[0,0,0,0]]
and that makes it go away, but that feels like a workaround.
Good catch: the problem was that when we don't find a good match (ie: when the exclusion zones prevent it), we may merge the remaining regions and this may then include areas that should be excluded. r14417 fixes that by re-excluding the zones after we find the best match. This does mean that it is possible for us to end up with a region that is not necessarily the best match.. (r14418 reduces the risk a bit) but changing this behaviour would be:
That did it. Looks weird(well, obviously...), but works as expected. Closing.
See also #1060
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1295