locked
App works on all devices except Surface 2 and Lumia 2520

    Question

  • We've published a Store app that works on all devices except Surface 2 and Lumia 2520.  The issue is that the bitmap in the scrollviewer doesn't scale properly.  It works on desktops and first-gen Surface without issue.

    Is there a way we can determine if this is a software bug on our side or a firmware bug in the device itself?

     auto h2 = m_sizeForZoom.Height;
     auto w2 = m_sizeForZoom.Width;
     auto u = (unsigned int)((PVOID)this);
     auto is = dynamic_cast<OurImageSource^>(m_conn->_Bitmap);
     if (is == nullptr)
     {
      return;
     }
     double h1 = is->pixelHeight;
     double w1 = is->pixelWidth;
     double z1 = h2/h1;
     double z2 = w2/w1;
     double zf1 = min(z1, z2);
     double zf = min(zf1, 1.0);
     this->RemoteDesktopScrollViewer->ChangeView(0.0, 0.0, (float)zf);

    Monday, April 14, 2014 8:49 PM

Answers

  • Heads-up to avoid duplicate effort.

    Thank you for your assistance so far, it is appreciated.  We're going to move forward by opening a support case.  


    Thursday, April 24, 2014 5:29 PM

All replies

  • Remember that these devices render at a higher pixel density. You may have to adjust for that. Can you post a complete simplified project to OneDrive that will demonstrate the issue? 

    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, April 15, 2014 12:11 PM
    Moderator
  • Thanks.

    I don't think the pixel density would affect those calculations in this case.

    App here

    Screenshots:

    1) http://1drv.ms/1eK51C5

    2) http://1drv.ms/1eK4QXi

    Screenshot 1: On Surface RT and all other devices, would normally be scaled to fit in that frame instead of filling it the way it does in that screenshot
    Screenshot 2: After pinch to zoom, the remaining portion of the image would normally be visible, in this case it's not on Surface 2 and Lumia 2520, but it is on all other devices

    We can't always replicate these types of bugs with simplified projects -- they sometimes just don't replicate. 

    Please let me know if we should still try to create a simplified project, or if there's some other debugging you can suggest.

    Tuesday, April 15, 2014 12:32 PM
  • OK, let's approach it this way then.  What specifically to you believe is a bug here?  Have you drilled into this code in the debugger and compared values on the different systems?

    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, April 15, 2014 12:40 PM
    Moderator
  • I don't see a screen shot of your app in the images shared.  I tried running the application on my Surface Pro 2 and it requires an account.  Please share images of the actual problem within your application.  And yes, if you can dumb this down to a simple app with a single image, and your pinch to zoom logic.  Remove login, background task requirements, etc...

    As for investigating the issue I would add debug logging to the events you are using for pinch to zoom as it appears it may have something to do with that.   Also keep an eye out in the debugger output window for any exceptions, and enable those to break to see if they are related.



    Bret Bentzinger (MSFT) @awehellyeah

    Tuesday, April 15, 2014 4:05 PM
    Moderator
  • Hi Bret,

    It's a remote desktop app.  That black "frame" you see around the outside is the only UI on the Surface 2.  The rest is the image from the remote PC (in this case, the remote PC has its start screen up).  The screenshots show the two states:  zoomed and unzoomed, on the same remote desktop image.  

    On a regular PC (higher resolution than Surface 2) the issue does not replicate.  We're working on getting it going with an emulator and in the process of trying to get some data to share with you.  

    The most recent note I have from the devs is this:


    auto h2 = m_sizeForZoom.Height; 

    auto w2 = m_sizeForZoom.Width;

    is taken from SizeChanged event. The documentation says that they are in pixels. Maybe they are scaled. I don't know.

    The ScrollViewer is the piece we think might have a bug (just speculation right now).  Since we don't have the source code, it's hard to tell, but I should have some more info in the next day or two.

    As for trying the app:  you can take out a free account/free trial by clicking "Sign-up" toward the bottom right if you want, or reach out to me, and I'll give you the Windows Store Testers' password.

    To be frank, making a simple app has not been successful for us in the past for replicating these types of bugs.  If you look in our MSDN account, you'll get a better feel for our history with that and XAML bugs.  Again, still not 100% sure it's not a bug in our app, so stay tuned.

     


    • Edited by Sir Scrump Tuesday, April 15, 2014 4:39 PM
    Tuesday, April 15, 2014 4:34 PM
  • Update:  It looks like it's thepixel denisty that causes the issue.

    In an emulator:

    • 23" 1920 x 1080 - the issue does not replicate
    • 10.6" 1920 x 1080 - the issue replicates

    So pixel density seems to be the issue, as Jeff originally said.  Still digging...

    Tuesday, April 15, 2014 5:10 PM
  • Can anyone help with this question? ...  Any docs are appreciated.

    How is the scrollviewer behaviour affected by the DisplayInformation.ResolutionScale?


    • Edited by Sir Scrump Tuesday, April 15, 2014 5:52 PM
    Tuesday, April 15, 2014 5:49 PM
  • The scrollviewer itself is not.  However there are many different ways you could create problems for yourself trying to manually layout things if you are not using functions that are display aware.

    I suggest your developer open a support case at this point if he is still roadblocked and you cannot share a repro project to debug.


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, April 15, 2014 5:56 PM
    Moderator
  • We created a repro project that draws a checkerboard.

    http://1drv.ms/1f97Exx

    It behaves differently, but still problematic. 

    • In the emulator, it reproduces the bug outlined above.  That is, checkerboard is drawn and when set to 23" 1920 x 1080, and the scaling issue does not replicate.  But at 10.6" 1920 x 1080 the issue above replicates with respect to the scaling being "off"
    • On a physical Surface RT, the screen comes up black:  The checkboard is not drawn at all
    • On a physical Surface 2 (RT), the screen is black:  The checkerboard is not drawn at all

    This differs from the original problem description, where our app works on Surface RT but not on Surface 2.  Not sure if the mini-project has introduced its own bug.  It's strange that the emulator draws the checkerboard, though, but not physical devices, and if I had to guess, is probably related to what we're seeing in our production app.

    Any ideas?

    Sunday, April 20, 2014 5:44 PM
  • To be clear,

    Now you are showing the problem is not related to the scroll viewer correct?

    I don't want to be chasing down something in scroll viewer if it has nothing to do with it or if this is a different problem.


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Monday, April 21, 2014 2:35 PM
    Moderator
  • The problem in production presents itself in the ScrollViewer.  In this sample application, the problem is different.  We believe that the sample application is the same, but its behaviour is different from what we see in production.  I'm not sure what to suggest. 

    For the sake of clarity:  in both production and in the sample our application draws a frame around the outside of the screen image in the ScrollViewer.

    1. In production (remote screen image)

    1. the frame is visible on all devices, including the Surface 2 and Lumia 2520, but the image in the ScrollViewer has a rendering problem detailed above
    2. On all other devices, the frame and image in the ScrollViewer renders and scales properly.

    2. In the sample application (coded checkerboard pattern)

    1. In the emulator:  the frame and image (checkerboard) are rendered correctly, but we can replicate the issue in 1.1 by setting 10.6" 1920 x 1080
    2. On any Surface (RT and 2) physical device:  neither the frame nor the image (checkerboard) are rendered at all.  We just get a black screen

    There may be a new bug in the sample application.  If there is please accept my apologies in advance.  Given that it works in the emulator and not on any physical device, it is a really tough for us to troubleshoot.

    Monday, April 21, 2014 2:46 PM
  • To offer a bit of context, here's a video of how the app works.  At 2:00 you'll see the "frame", at 3:58 the zooming behaviour when it's working properly.  If this isn't suited to a forum post, please advise and I'll open a ticket with support.
    Monday, April 21, 2014 9:54 PM
  • Thanks for the video.  In the Checkerboard demo I see most of the scales misbehaving.  How are you determining the correct scale for displaying?  I don't see any device measurement or calculations?

    If you want personal 1:1 support and this is time sensitive then yes, you should create a support case here: https://getsupport.microsoft.com/default.aspx?locale=EN-US&supportregion=EN-US&ccfcode=US&mkt=EN-US&pesid=14654&oaspworkflow=start_1.0.0.0&tenant=store&supporttopic_L1=31762109&ccsid=635337386332939119


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, April 22, 2014 11:44 AM
    Moderator
  • I'm not sure what you're seeing that causes you to think it's misbehaving, but there aren't any device measurement calculations per se.

    • When the checkerboard is loaded, the grid is 1366x768 pixels; 14 "x" checkers by 8 "y", with each checker at 100x100px except the last checkers in each column and row.
    • On initial load the whole thing is scaled to fit within the frame (note:  don't dynamically change the resolution/device size, it's not a practical use-case and not something that we've coded for)

    We can tell there's a problem with the checkerboard if it isn't scaled to fit the frame and zooming causes other checkers that should be visible not to be visible.  All checkers should be visible on zoom out.

    Specific only to the checkerboard sample app, it has the additional effect of working in the emulator but presenting a black screen on a physical device; in contrast to our production app which does not have that effect.

    Any other questions, let me know.


    • Edited by Sir Scrump Tuesday, April 22, 2014 12:59 PM
    Tuesday, April 22, 2014 12:58 PM
  • Heads-up to avoid duplicate effort.

    Thank you for your assistance so far, it is appreciated.  We're going to move forward by opening a support case.  


    Thursday, April 24, 2014 5:29 PM