SpiderVision cannot set two viewports with ExclusiveFullscreen on two displays

[Amerio.Stephane]

Hello

• create a new 2.21 IG project on a PC with two physical display attached
• launch and F10 into spidervision
• create two viewports, assign each one to a display and set them to Exclusive Fullscreen
  • view_0 => display_index=0
  • view_1 => display_index=1
• save to data/default.sv
• quit and restart
  • both viewport try to be Exclusive Fullscreen at the same time on the same display (?), causing infinite flickering

At the moment, the only way around this is to use Borderless Windows, but this can cause other issues with other displayed app and the taskbar.

Note: we target displays at 1280x720@50Hz to simulate dual-sensors.

[bmyagkov]

Hi Stéphane,

Thanks for the detailed reproduction steps. Looking into this:

The flicker you see on restart is expected given how the engine's window manager handles exclusive fullscreen. By design, only one EngineWindow can hold exclusive fullscreen at a time: when any viewport calls enableFullscreen(), the WindowManager forces fullscreen off on every other window first. When SpiderVision loads default.sv and both viewports are set to Exclusive Fullscreen, they take turns kicking each other out of fullscreen every frame, which produces the infinite flicker.

This also aligns with how Windows itself behaves. True exclusive fullscreen (DXGI SetFullscreenState) is built around the assumption that one app owns a display mode at a time.

So, using the Borderless Windowed approach would be our general recommendation.

Speaking of the issues you mentioned in that context, could you describe in more detail what exactly you ran into?

Basically, a Borderless Windowed view should fully cover the taskbar of its target monitor as long as the window position is (0, 0) and the window size matches the physical resolution of that monitor (the display_index in SpiderVision selects which monitor it lands on). So at the moment it is not entirely clear to us which exact problems you ran into any extra detail on your side would help us narrow it down.

Thanks!

[Amerio.Stephane]

Ok, got it for the Windows behavior and Exclusive Fullscreen. We've been using Borderless Windows until now, but that means we need to set up the Windows desktop to use the target resolution and frequency for the standard desktop, and that can be somewhat uncomfortable (being on a 1280x720 desktop...). But we can live with that and use other tools to maybe change the resolution right before launch. Thanks for the clarification!

The other issue I was referring to is (I think) a Win11 quirk. Our app is launched non-interactively from a network command by a custom launcher. And sometimes, Windows decides that even though Unigine is flagged to be TopMost, well, the taskbar and any other desktop app can still be in front, requiring the user to manually go to the sensor PC and simply click in the Unigine windows to raise it to the top (even though, again, it's flagged as topmost, or even exclusive). Maybe you've already encountered this in latest Win11 (this was never occurring in Win10 or old Win11).

[bmyagkov]

Hi Stéphane,

Thanks for the extra context, both points are now clearer on our side.

Regarding the Windows 11 focus issue, this is the first time we've come across this exact behavior in the context of a non-interactive launch. On the engine side, one thing that might be worth trying in the meantime is to explicitly force focus on the engine windows once the SpiderVision configuration is loaded. EngineWindow exposes two relevant methods:

• setFocus() https://developer.unigine.com/en/docs/2.21/api/library/gui/class.enginewindow#setFocus_void
• setSystemFocus() https://developer.unigine.com/en/docs/2.21/api/library/gui/class.enginewindow#setSystemFocus_void

After the .sv config is applied, you can iterate over all existing EngineWindow instances and call one of these on the main one. setSystemFocus() in particular asks the OS to bring the window to the foreground, which is closer to what you need here. It is not a guaranteed solution, since modern Windows actively restricts which processes are allowed to steal foreground focus from a non-interactive session, but it's worth checking whether it changes the behavior on your side.

Thanks!

[Amerio.Stephane]

Yes, I tried this already, and Win11 still sometimes prevent the focus to go to the window. Not on all PC, not everytime, what a time-waster of an OS... Anyway, thanks for the info. Another 'funny' thing with this win11: even if the taskbar is minimized, upon launch of our app the taskbar may come up to the front, just to say 'hi, a new app is here'. Last resort is to simply kill explorer.exe but that opens another can of worms...