Windows phone 10 black borders

Interesting.  If you look at the results of the Lumia 550 and 640XL, notice that the “Resolution Scale” and “Content Scale” differ.  A ContentScale of 1.0 is wrong for those devices, but the ResolutionScale of “Scale150Percent” is correct.  And the LogicalDPI of 144 is correct for both of the devices too.  This is good news.  This means we can implement a work-around.  All we have to do is compare the 2 scale factors (which are supposed to be the same; that’s the Microsoft bug) and choose the greater value.  Thanks for this @primoz:slight_smile:

I was also able to reproduce this bug in the Windows 10 Mobile emulators too, but only if they’re set up as follows:

  • Must be a 720P or WXGA resolution Win10 emulator.  (WVGA, 1080P, and QHD scale correctly.)
  • Must be set up to use a software navigation bar.  (Scales correctly if emulating with hardware buttons.)

You can enable the software navigation bar in the Windows Phone emulator by doing the following:

  1. Launch the Windows 10 Mobile emulator via Visual Studio.
  2. Click the [>>] button on the floating toolbar to the right of the emulator to show the “Additional Tools” window.
  3. Click on the “Optional Settings” tab.
  4. Check the “Software buttons” checkbox.
  5. Click the Apply button.  (This will cause the emulator to reboot.)

After doing the above, the emulator reports the same values you’ve noted on the Lumia 550 and 640 XL where the “ContentScale” property returns the wrong value but the “ResolutionScale” property returns the correct value.  This is a big help to us.

So, I’ll go ahead and implement a work-around today and try to get you guys a daily build as soon as possible.  Again, thanks for your help on this.

Unfortunately, the Lumia 535 appears to be a lost cause.  Notice that all of Microsoft’s APIs return the wrong values for that device.  The above mentioned work-around will not work on this device.  The only possible solution that I can think of is to identify that device by its make/model name and if it is a Lumia 535, then assume hardcode the resolution and scale factor on our end.  *ugh* I would prefer not to hardcode hacks like this since they’re a maintenance issue on our end, but if it’s a popular device then we may consider doing it.  I’ll have to ponder our options.

Regarding the WP8 version of Corona Cannon, I don’t have access to the code either.  But I’ll reach out to the developer on how it’s set up.  :slight_smile:

Thank you Joshua! Please let us know when daily build with work-around available. I’ll be happy to test.
 

Regarding Lumia 535, it would be great to put hack into daily build. +1 from my side (need to update 40 apps, and don’t want to do it twice :-) ).

Okay. I need you to do 1 more test for me. Please run the following code on your Lumia 535 and tell me what it outputs…

System.Diagnostics.Debug.WriteLine("### DeviceManufacturer: {0}", Microsoft.Phone.Info.DeviceStatus.DeviceManufacturer); System.Diagnostics.Debug.WriteLine("### DeviceName: {0}", Microsoft.Phone.Info.DeviceStatus.DeviceName);

The above is needed in order for me to identify your Lumia 535 device in code. Thanks!

Everyone,

Daily build #2860 will provide our work-around for those Windows 10 Mobile scaling bugs you’ve seen on devices having an onscreen navigation bar.  Just note that this is a “blind fix” since I can’t reproduce this issue on my devices.  I can only sort-of reproduce it in the Windows Phone emulators.  Please let me know how it works out for you all.  Also note that it won’t solve the problems you are seeing with the Lumia 535 unfortunately.

Please test the new build with the following “main.lua” code.  The following project does not need a “config.lua” file.  The content area will be displayed white, and if you do add a “config.lua” file, then the letterbox areas will appear red.

-- Hide the status bar. display.setStatusBar(display.HiddenStatusBar) -- Display a black bacground rectangle in Corona's content region and red in the letterbox region. local backgroundRectangle = display.newRect(0, 0, 0, 0) --backgroundRectangle:setFillColor(0, 0, 0) backgroundRectangle:setFillColor(1, 1, 1) display.setDefault("background", 1, 0, 0) --display.setDefault("background", 1, 1, 1) -- Define the rest of our variables. local textObject = nil local textGuideLineTop = nil local textGuideLineBottom = nil local textGuideLineLeft = nil local textGuideLineRight = nil -- Creates a red horizontal line at the given position within the content region. -- It will not draw the line in the letterbox region. local function createHorizontalGuidingLineAt(positionY) local line = display.newLine(0, positionY, display.contentWidth, positionY) line:setStrokeColor(1, 0, 0) line.strokeWidth = display.contentScaleY -- Set line width to 1 pixel. return line end -- Creates a red vertical line at the given position within the content region. -- It will not draw the line in the letterbox region. local function createVerticalGuidingLineAt(positionX) local line = display.newLine(positionX, 0, positionX, display.contentHeight) line:setStrokeColor(1, 0, 0) line.strokeWidth = display.contentScaleX -- Set line width to 1 pixel. return line end -- Creates and/or updates all display objects to fit the window. local function updatePositions() -- Update the text object. local pixelWidth = display.pixelWidth local pixelHeight = display.pixelHeight if ((system.orientation == "landscapeRight") or (system.orientation == "landscapeLeft")) then local length = pixelWidth pixelWidth = pixelHeight pixelHeight = length end local message = "Window Size: " .. tostring(pixelWidth) .. "x" .. tostring(pixelHeight) .. " pixels" print(message) print("Content Size: " .. tostring(display.contentWidth) .. "x" .. tostring(display.contentHeight)) print("Orientation: " .. tostring(system.orientation) .. ", Content Scale: " .. tostring(display.contentScaleX)) if textObject then textObject.text = message textObject.size = 0 textObject.x = display.contentCenterX textObject.y = display.contentCenterY else local textSettings = { x = display.contentCenterX, y = display.contentCenterY, text = message, align = "center", } textObject = display.newText(textSettings) -- textObject = display.newEmbossedText(textSettings) textObject:setFillColor(0, 0, 0) end -- To prevent text blurriness, make sure it is displayed on a whole pixel. local xInPixels = textObject.x \* display.contentScaleX local yInPixels = textObject.y \* display.contentScaleY local xOffset = (math.floor(xInPixels) - xInPixels) / display.contentScaleX local yOffset = (math.floor(yInPixels) - yInPixels) / display.contentScaleY textObject:translate(xOffset, yOffset) -- Update the black background rectangle to fit the content region. backgroundRectangle.x = display.contentCenterX backgroundRectangle.y = display.contentCenterY backgroundRectangle.width = display.contentWidth backgroundRectangle.height = display.contentHeight -- Re-position the text object's guiding lines. local bounds = textObject.contentBounds if (textGuideLineTop) then textGuideLineTop:removeSelf() end if (textGuideLineBottom) then textGuideLineBottom:removeSelf() end if (textGuideLineLeft) then textGuideLineLeft:removeSelf() end if (textGuideLineRight) then textGuideLineRight:removeSelf() end textGuideLineTop = createHorizontalGuidingLineAt(bounds.yMin) textGuideLineBottom = createHorizontalGuidingLineAt(bounds.yMax) textGuideLineLeft = createVerticalGuidingLineAt(bounds.xMin) textGuideLineRight = createVerticalGuidingLineAt(bounds.xMax) end updatePositions() -- Called when the window has been resized. Re-layouts the app display objects to fit. local function onResized(event) updatePositions() end Runtime:addEventListener("resize", onResized) -- Called when a key has been pressed/released. local function onKey(event) -- If this is a Windows app, then toggle fullscreen mode via the F11 key. if (system.getInfo("platformName") == "Win") and (event.keyName == "f11") and (event.phase == "down") then local windowMode = native.getProperty("windowMode") if (windowMode == "fullscreen") then native.setProperty("windowMode", "normal") elseif (windowMode ~= nil) then native.setProperty("windowMode", "fullscreen") end end end Runtime:addEventListener("key", onKey) system.activate( "multitouch" ) local touchCircles = {} local function onTouch(event) if (event.phase == "began") then local circle = display.newCircle(event.x, event.y, display.contentWidth \* 0.2) circle:setFillColor(0, 0, 1, 0.75) touchCircles[event.id] = circle elseif (event.phase == "moved") then local circle = touchCircles[event.id] if circle then circle.x = event.x circle.y = event.y end elseif (event.phase == "ended") or (event.phase == "canceled") then local circle = touchCircles[event.id] if circle then touchCircles[event.id] = nil circle:removeSelf() end end end Runtime:addEventListener("touch", onTouch)

The above project will display a circle when you touch the screen.  Can you please drag your finger from top to bottom on the screen to verify that the circle is always centered around your finger please?  This tests that our touch coordinates are being correctly converted to pixels.

Also note that I *suspect* that your Lumia 550 and 640 XL might display a red or black rectangle onscreen.  I say this because the height being reported by Microsoft’s APIs are a little short for those devices.  I’m guessing that Microsoft made it that way on purpose and that the bottom navigation bar no longer overlays on top of Silverlight apps like how it did on Windows Phone 8.1.

Thank you! I am unable to download #2860. It is not visible yet… Will test when available.

Lumia 535 output with DeviceName >>>

Resolution Scale: Scale100Percent

Content Scale: 1

Content Size: 480x800

Page Size: 480x771

CoronaPanel Size: 480x771

RawDpiX: 196,645161290323

RawDpiY: 196,645161290323

PhysicalScreenResolution: 480x800

Logical DPI: 96

DeviceManufacturer: Microsoft

DeviceName: RM-1089_1024

Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 305 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2830

The WP8 CoronaCards daily build with this work-around is available now.

If you can test it out with the above “main.lua” code I posted above and do that touch test, then that would be great.  Thanks.

Regarding the Lumia 535 device, you guys said if you disable fullscreen rendering, then it was displayed correctly, right?

If so, then please try changing your MainPage() constructor code to the following.  It’ll reduce your framerate on the device to 30 FPS, but I’m not sure what else to do on this device.

public MainPage() { // Initialize this page's components that were set up via the UI designer. InitializeComponent(); // Set up Corona to automatically start up when the control's Loaded event has been raised. // Note: By default, Corona will run the "main.lua" file in the "Assets\Corona" directory. // You can change the defaults via the CoronaPanel's AutoLaunchSettings property. fCoronaPanel.AutoLaunchEnabled = true; // Set up the CoronaPanel control to render fullscreen via the DrawingSurfaceBackgroundGrid control. // This significantly improves the framerate and is the only means of achieving 60 FPS. fCoronaPanel.BackgroundRenderingEnabled = true; fDrawingSurfaceBackgroundGrid.SetBackgroundContentProvider(fCoronaPanel.BackgroundContentProvider); fDrawingSurfaceBackgroundGrid.SetBackgroundManipulationHandler(fCoronaPanel.BackgroundManipulationHandler); // Disable fullscreen rendering on the Lumia 535 device if it's running Windows 10 Mobile // Note: This device has bugs where it reports the wrong resolution and scale factor. if (Environment.OSVersion.Version.Major \>= 10) { var manufacturerName = Microsoft.Phone.Info.DeviceStatus.DeviceManufacturer; var modelName = Microsoft.Phone.Info.DeviceStatus.DeviceName; if (!string.IsNullOrEmpty(manufacturerName) && !string.IsNullOrEmpty(modelName)) { manufacturerName = manufacturerName.Trim().ToLower(); modelName = modelName.Trim().ToLower(); switch (manufacturerName) { case "microsoft": case "microsoftmdg": case "nokia": if (modelName.StartsWith("rm-1089") || modelName.StartsWith("rm-1090") || modelName.StartsWith("rm-1091") || modelName.StartsWith("rm-1092")) { fCoronaPanel.BackgroundRenderingEnabled = false; } break; } } } }

Run the above with the “main.lua” test code that I’ve posted and test Corona’s touch events.  Drag your finger from the top of the screen to the bottom and make sure that the touch/drag circle is always centered around your finger.

Bad news.  I’ve done some more testing with the newest build on different Win10 resolution devices… but unfortunately apps are still scaling incorrectly.  And “touch” and “tap” points are offsetted too.  Each different resolution devices (WXGA, 720P, and 1080P) are all broken in their own way and there is no single reliable Microsoft API for us to use.  So, it looks like we have no choice but to avoid high-performance rendering via the “DrawingSurfaceBackgroundGrid” just as @primoz as suggested.  Unfortunately, the negative consequences of not rendering straight to the background is…

  1. You can’t render at 60 FPS.  Rendering is significantly slower.

  2. The displayed contents will be blurry.  On a 720P device, it’ll render at 480x800 scaled up.  On a 1080P device, it’ll render at 768x1280 scaled up.

I *think* I’ve found a reliable way of detecting when Windows 10 Mobile’s UI scaling is broken.  So, I think I can rig CoronaCards to not do fast background rendering on these devices.  This way, users of Windows 10 Mobile devices that have physical navigation buttons (aka: the ones that don’t have scaling bugs) will have fast rendering using the actual resolution of the device.

I’ll look into this tomorrow.  Thanks for your patience.  And sorry about the inconvenience.

I have tested newest CC on my devices. There is still black border on top (portrait), and touches are wrong. Anyway, black border on top is smaller. There is no more black border from side.

Maybe another workaround is to disable Nav buttons? In corona cannon they are hidden. How can I achieve this?

Thank you for all your work and help!

I acquired the WP8 Corona Cannon project yesterday.  When I run it on a Windows 10 Mobile device that has an onscreen navigation bar, it has the exact same scaling problems you guys mentioned.  So, I’m not sure how it could scale correctly for you @primoz.  And the C# code hasn’t been changed at all.  Pretty much everything was left at its defaults, except for the app name and icon/tiles of course.

And as far as I know, there are no native APIs for showing/hiding the bottom navigatoin bar in Silverlight apps.  And the 1 Silverlight API for enabling/disabling fullscreen mode only hides/shows the top statusbar, not the bottom nav bar.  And my understanding is that Windows 10 Mobile doesn’t allow users to swipe away the bottom nav bar while running a Silverlight app… but Windows 10 Mobile isn’t supposed to overlap the bottom nav bar on top of a Silverlight app anyways.  On Windows Phone 8.1, the bottom nav bar does overlap the app, but can always be dismissed by the user. Anyways, that’s been my experience.

Daily build #2861 will provide a much more reliable work-around for this issue.  Once the daily build becomes available, please give it a go and let me know how it works for you.  The scaling issues should be gone in that build.  But since my only recourse is to implment what I’ve mentioned in the above post, the framerate will be worse and the graphics will appear scaled up.  Not sure what else we can do at this point.

Have tested #2861, but it works so slow that we can not use it. Max framerate is 30, most of the time lower than 15. If I build one of our game with #2830 and comment out lines regarding BackgroundRenderingEnabled, then it works much faster and it is rendered almost correctly :). At bottom only about 5px are missing… It is overlapped by nav buttons. Max frame rate is 55, but newer lower than 40.

When Corona Cannon is started on my Lumia WP 10 devices, nav buttons are hidden and Corona Cannon downloaded from MS Store works perfectly in full screen, on all my WP 10 devices. I am unable to reproduce this behavior when I build Corona Cannon.
Looks like it has something to do with versions used when building game (VS or CC)?

>> Looks like it has something to do with versions used when building game (VS or CC)?

Nope. Corona Cannon was built with Visual Studio 2013.  No C# changes were made to the project template.  When I build it and run it on a Lumia 550, I can see the same scaling issue as you.  But if I install the Corona Cannon app on the same device from the app store, it does not have any scaling issues and it allows me to swipe the bottom navigation bar on/off the screen.

So, I’m starting to *think* that this bad behavior only happens when you side-load the app onto your Windows 10 Mobile device.  If you take the same app you built and install it via the Microsoft app store, then your app will behave more like a Windows Universal app without the scaling issues and with a dismissible navigation bar.  (Well, except on the Lumia 535 unfortunately.)

To test this theory I’ve installed other Corona made apps such as “My Boo”…

   https://www.microsoft.com/en-us/store/apps/my-boo/9wzdncrdgbjx

And “Feed OmNomster”…

   https://www.microsoft.com/en-us/store/apps/feed-omnomster-the-hungry-monster/9wzdncrdlbnb

Both of the above apps do not have scaling issues and the bottom navigation bar is dismissible.

Try testing you own app currently on the app store on a non-Lumia 535 device, such as a Lumia 550 or Lumia 640 XL.  I’ll bet it’ll display correctly on those devices.

>> At bottom only about 5px are missing… It is overlapped by nav buttons

Yes, I’ve noticed the same thing on a 720P and WXGA resolution devices.  Unfortunately, there is nothing we can do about it.  Microsoft is incorrectly sizing the Silverlight native UI (ie: the MainPage) just under the navigation bar.  And there are no native Silverlight APIs to give us any navigation bar information.  So, there’s nothing more we can do.

>> If I build one of our game with #2830 and comment out lines regarding BackgroundRenderingEnabled, then it works much faster

Yeah, I noticed the performance issue too.  The daily build you tested effectively prevents you from enabling background rendering, but unfortunately those SetBackgroundContentProvider() and SetBackgroundManipulationHandler() method calls cause a severe performance issue too because they’re unnecessarily calling our code on every frame.  I’ll look into getting you guys another update soon to resolve the performance issue.

Everyone,

Give daily build #2682 a try, which should come out sometime tomorrow.  This build will significantly improve the performance on the Windows 10 Mobile device having an onscreen navigation bar, while still providing that scaling work-around we’ve added in build #2681.  This work-around effectively disables background rendering for you so that don’t have to do it yourself in your MainPage code… *AND* it’ll only do so if Corona detects this scaling bug in Microsoft’s APIs (such as the 2 native scale factor APIs returning different values).

Have tested #2682, it is slow, but it works. Already updated our apps. Thanks! 

Are you using Microsoft’s preview/beta of Windows 10 Mobile on your device?

I ask, because Microsoft did state that there were known scaling bugs with some device models on their end.  Case-in-point:

   http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_update/lumia-640-users-check-here-for-windows-10/e45ddf8c-5660-44bf-aa16-4a2d23c59883?auth=1

The released version of Windows 10 Mobile shouldn’t have these scaling issues.  You can upgrade your phone to the released version of Windows 10 Mobile by downloading Microsoft’s “Upgrade Advisor” from the Windows app store.

I’ve also tested WP8 CoronaCards with the release version of Microsoft’s Windows 10 Mobile emulators.  There is no scaling issues there either.  You can download these emulators via the link below, by clicking that page’s “Download the emulator” link.  That’ll download an install program providing several emulators at different resolutions and different amounts of RAM.

   https://dev.windows.com/en-us/downloads

Good evening, thank you for help.

My phone is with the final version of windows phone 10 testing applications made in corona sdk works normal, the problem is only in mine.

Some who have tested and worked regular:

wp_ss_20160324_00021.png

wp_ss_20160324_00031.png

It works well, am I using the latest version of Corona?

I use v2016.2830

Okay.  So, you’re saying that it works fine on all Windows 10 Mobile device except yours?

Can you tell me the make and model of your device please?  (Example: Lumia 950)

I’m still thinking it’s a bug on Microsoft’s end and that they’re returning the wrong scale factor on the device as mentioned in the link I posted above.  If this is a Microsoft bug that accidentally got released on some devices, then we’ll have to investigate a work-around.  But step 1 is for someone on my end to reproduce this issue.

One more thing.  You *could* try to retarget your project to Windows Phone 8.1.  By doing this, your app will be able to take advantage of 1080P and higher resolution devices (it’ll no longer appear scaled and slightly blurry on those devices), but then you’ll lose 8.0 support.  Your app will only be able to run on 8.1 and 10.  I don’t really recommend it, but it’s worth a try in case there is a backward compatibility bug on Microsoft’s end.  Here’s how to re-target your project:

  1. Open your project in Visual Studio.
  2. Right click on your project in the “Solution Explorer” panel.
  3. Click on “Retarget to Windows Phone 8.1” in the popup menu.
  4. Save and rebuild.

I have the same trouble on my lumia 535. I use released version of Windows 10 with latest updates.

Sometimes the trouble disappears, but reappears after making new build. The reason I can’t identify :frowning:

“Retarget to Windows Phone 8.1” doesn’t solve the trouble.