Unfortunately I think you would need to debug through the window creation code to find where the windows task bar limitation is coming from, I suspect this isn’t a very common case - it’s rather unusual to have a full screen window (that isn’t just full screen), and there’s generally no reason for PIE windows to be full screen.
In the UMoviePipelinePIEExecutor::Start function, where it create sthe custom window to be used by the PIE session:
// Create a Slate window to hold our preview.
TSharedRef<SWindow> CustomWindow = SNew(SWindow)
.ClientSize(WindowSize)
.AutoCenter(EAutoCenter::PrimaryWorkArea)
.UseOSWindowBorder(true)
.FocusWhenFirstShown(true)
.ActivationPolicy(EWindowActivationPolicy::Never)
.HasCloseButton(true)
.SupportsMaximize(true)
.SupportsMinimize(true)
.SizingRule(ESizingRule::UserSized);
WeakCustomWindow = CustomWindow;
FSlateApplication::Get().AddWindow(CustomWindow, !IsRenderingOffscreen());
Looking through SWindow’s arguments, there’s one called “SaneWindowPlacement”, which has this description:
/** If the window appears off screen or is too large to safely fit this flag will force realistic
constraints on the window and bring it back into view. */
SLATE_ARGUMENT( bool, SaneWindowPlacement )
It defaults to true, you could try changing the engine code for the Movie Pipeline PIE Executor to set that to false to see if that is what is causing the window to be clamped to the screen area not counting the task bar.
> I suppose the rendering of same frame is happening twice? (output log of two resolutions also seem to be confirming this).
Yes and no. The regular game viewport is being rendered, but MRQ is disabling the rendering of the 3d world within that viewport (which is why the background of the PIE session is black, despite the debug widget not actually providing a background). So the actually intensive part of rendering is skipped during the rendering of the view, and in general, the rendering system pools render target resources (ie: there isn’t a separate set of render targets just for the game-world separate from the MRQ render, the same one would be re-used, since the only unique output between renders is a single full-screen image and not the full heavy gbuffer). So there shouldn’t really be any noteable performance gains left on the table, the 3d render is the heaviest performance component. Additionally the world is only ticked once per frame, MRQ just requests a different render of the world after being updated by the game.