QA » openQA Project

It looks like the isotovideo normally aims for a 1 second update interval. (The function _calc_check_delta in isotovideo checks how much time has passed since the last update and sets the timeout for a 1 second interval.) In case a screen is to be asserted with no_wait option the timeout is reduced to 0.1 seconds. However, all of this is only the interval for calling the backend's check_asserted_screen function. That function will only request a screen update (via VNC) in certain cases, though.

The backend's interval for requesting VNC updates is actually only influenced indirectly via $bmwqemu::vars{SCREENSHOTINTERVAL} which is by default 0.5 seconds. (The update interval is actually half of it, so by default it is 0.25 seconds.)

So assuming defaults are in place, reducing the sleep in wait_screen_change will not make it faster because only when a new screenshot is enqueued the the last image is updated and that's used for this check.

Considering the code in do_capture of baseclass.pm it should be easy to add another variable (that could be set from autotest functions) to either change the screenshot (and possibly VNC update) interval dynamically or to enforce the next VNC update and screenshot immediately.

It would also be possible to decouple wait_screen_change from the screenshot creation and compare with the VNC framebuffer directly. I suppose then we'd also make sure that the VNC socket is drained (as this so far only seems to happen when capturing a screenshot or before an update request).

So far autotest needs to poll the backend in wait_screen_change (with that 0.5 seconds sleep). Maybe it would be nicer if the backend would provide a synchronous call instead. So the backend would simply postpone the reply to the call until the screen changes or a timeout is reached. That would eliminate this one sleep altogether. The call would also be able to lower the screenshot interval to waste less time.

This PR shows how removing the sleep-loop in the autotest completely would look like: https://github.com/os-autoinst/os-autoinst/pull/2158

Then I could go ahead and add an option to make the backend reduce the time before enqueuing the next screenshot to waste less time on wait_screen_change calls.

Before that, I'll first give the refactoring a verification run. I'll try the scenario https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD-Updates&machine=64bit-2G&test=gnome&version=15.3 from the original ticket about chromium typing issues (#109737).

PR for actually implementing no_wait (based on the first PR): https://github.com/os-autoinst/os-autoinst/pull/2164