Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MonoGame 3.7.0.1708: SwapChainPanel Repaint Issues on Windows® 10 UWP (XAML) #6513

Open
AdrianWenz opened this issue Oct 27, 2018 · 5 comments
Labels
Windows 10 UWP UWP platform

Comments

@AdrianWenz
Copy link

When a 'SwapChainPanel' UIElement is placed inside a 'ScrollViewer' object and the visible area is scrolled to the left, the uncovered part of the swap chain panel is NOT drawn at all (see attached picture).
The previous version of MonoGame (3.6.) handled this correctly.

monogame 3 7 0 1708 scroll issue

Steps to reproduce this issue:

  • Create a 'MonoGame Windows 10 Universal (XAML) Project'
  • Change the file 'GamePage.xaml' to:
    <ScrollViewer x:Name="AppContent" VerticalScrollBarVisibility="Auto" HorizontalScrollBarVisibility="Auto" HorizontalScrollMode="Auto" VerticalScrollMode="Auto" ZoomMode="Enabled">
    <SwapChainPanel x:Name="swapChainPanel" MinWidth="768" MinHeight="640"/>
    </ScrollViewer>
  • Compile the project and launch it
  • Resize the application windows to be less than 768 px in width and scroll to content to the left

The sample project is attached.
Game1.zip

What version of MonoGame does the bug occur on:

  • MonoGame 3.7.0.1708

What operating system are you using:

  • Windows® 10 (17134.345)

What MonoGame platform are you using:

  • WindowsUWP
@AdrianWenz
Copy link
Author

AdrianWenz commented Oct 27, 2018

Something similar happens also in conjunction with the Mobile Emulators (10.0.15254.0):

monogame emulator

Running the original (unmodified) 'MonoGame Windows 10 Universal (XAML) Project' on the mentioned emulator (->x86), shows a swap chain panel (corn blue color) that covers only about half of the visible area.

Again, this behavior was not detected with the previous version of MonoGame (3.6.) i.e. was handled correctly.

@nkast
Copy link
Contributor

nkast commented Oct 27, 2018

I think what broke it was #5615.
I changed the code from _swapChainPanel.SizeChanged to _coreWindow.SizeChanged because now the inputElement/SwapChainPanel could be null under an CoreApplication projects and I assumed that a SwapChainPanel will always be the same size as the window.

The Phone case is a bit weird. I believe the cause of the bug is #5555, #5569.
However in 3.6, the _swapChainPanel would fire a SizeChanged right after startup and update the wrong Backbuffer size.

@AdrianWenz
Copy link
Author

@nkast
I've added some more pictures to illustrate the distorted aspect ratio on the mobile emulators:
After launching the application it looks as follows:

monogame 3 7 0 1708 i

Turning the emulator into the horizontal orientation and then back to vertical:

monogame 3 7 0 1708 ii

I hope this additional information helps to fix the reported issue.

@nkast
Copy link
Contributor

nkast commented Oct 28, 2018

For the distorted aspect ratio on phones apply the changes from #5569. I believe that will fix it.

As for the first issue with the SwapChainPanel in a ScrollViewer , I don't think MG can support it. When you change the backbuffer size for example, MG will also change the Window size to match that size. Therefore the SwapChainPanel must be the root element and fill the window without any borders/padding. For scenarios like the one you describe you would need something like a SwapChainRenderTarget for UWP #4674.

@AdrianWenz
Copy link
Author

@nkast
I want to state again here that BOTH issues are handled correctly by MonoGame 3.6. i.e. these bugs have been introduced by version 3.7.0.1708.

@Jjagg Jjagg added the Windows 10 UWP UWP platform label Dec 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Windows 10 UWP UWP platform
Projects
None yet
Development

No branches or pull requests

3 participants