Bug Report: Differences in Zoom behavior between SL, WP7, and HTML controls
Locked
-
Wednesday, November 09, 2011 8:46 PM
There is a lack of consistency in the behavior of the different flavors of controls when zooming a custom tile layer. If I have a custom tile layer with maximum content at zoom level 14 (Z14) here is the behavior I see for each type of control when zooming in beyond level 14:
- Silverlight: Content from the last valid zoom level is always displayed (Z14 is streched appropriately) at all zoom levels beyond 14. This behavior seems ideal for my application.
You can see this at www.deepzoom.com , go to coordinates: N47 53' 51", W122 23' 07" (the south tip of Whidbey Island, WA). - HTML: Beyond Z14 my custom tile layer disappears completely. Not good. Demo at www.deepzoom.com/BingMap.html .
- WP7: Beyond Z14 some much earlier layer is scaled (I believe it's Z12). This is disconcerting and the worst of both of the above options.
One added twist which may be affecting results is that I'm using a sparse dataset. That is, not all zoom layers are completely represented, and different zoom levels may have different coverage. The Silverlight control handles all of these vagaries correctly.
- Edited by jaybo_nomad Wednesday, November 09, 2011 8:47 PM
- Moved by Richard_BrundrittMicrosoft Employee, Owner Sunday, March 11, 2012 3:46 PM (From:Bing Maps: Map Control and Web services Development)
- Silverlight: Content from the last valid zoom level is always displayed (Z14 is streched appropriately) at all zoom levels beyond 14. This behavior seems ideal for my application.
All Replies
-
Friday, November 18, 2011 11:23 AMOwnerThe Silverlight control has added functionality for zooming into an image. The AJAX control may not have this and it's likely just a limitation in JavaScript. Note that the AJAX control has never zoomed into tile layers before and this control is the primary map control for Bing Maps. For WP7, I have not been able to reproduce this issue. I have been able to get my tile layers to act like the standard Silverlight control, however that required some work. The WP7 has some optimizations specifically around tile layers so that it will not request as many tiles as the silverlight control does. The Silverlight control downloads tiles in the background for the zoom levels you went through.
http://rbrundritt.wordpress.com- Proposed As Answer by Richard_BrundrittMicrosoft Employee, Owner Friday, November 18, 2011 5:23 PM
- Unproposed As Answer by jaybo_nomad Friday, November 18, 2011 7:30 PM
- Proposed As Answer by Richard_BrundrittMicrosoft Employee, Owner Tuesday, January 10, 2012 6:54 PM
- Unproposed As Answer by Richard_BrundrittMicrosoft Employee, Owner Tuesday, January 10, 2012 6:54 PM
-
Friday, November 18, 2011 7:19 PM
Here's a video of the WP7 bug. All of the necessary layers have been downloaded, but when zooming continues beyond the available layers, some earlier random layer (Z12?) is zoomed instead of a more appropriate layer (Z14).
You can verify this by looking at the text to the right of the purple blob (buoy) in the center of the display. It is the letter "G" in layer Z12, and the number "7" beyond Z12.
- Edited by jaybo_nomad Friday, November 18, 2011 7:30 PM
-
Monday, December 12, 2011 10:17 PM
As I've spent more time with the WP7 control and custom tile sets, I notice it sometimes switches to a lower zoom level in the midst of an animated zoom even if all tiles are available for both lower and higher adjacent zoom levels. This causes an unpleasant "flash" of improper tile data before the correct zoom level is finally used at the end of the animated zoom.
So this is one more area where the WP7 zoom performance for custom tile layers is worse than that of the Silverlight control, which always displays the same tile set smoothly and correctly.
-
Friday, December 30, 2011 12:17 AM
Since somebody else is seeing the same rendering issues with the WP7 control as I described above (which is killer from a usability standpoint):
I thought it would be nice to give a demonstration of how the forum staff could be a bit more proactive in dealing with bug reports, especially since this is the only bug reporting venue for Bing map controls:
We have confirmed this issue is a bug in the WP7 control. It has been added to the official buglist. It is scheduled to be fixed in the next drop of the control. While we can't offer specific dates it is likely this will be available in Q1 2012.
or, alternatively ...
Sorry, we have been instructed to provide no useful information regarding our development process. While we understand this may alienate our developer base and cause you to seek alternative technologies, we believe a "loose lips sink ships" policy to be best for everyone.
-
Wednesday, January 11, 2012 5:37 PM
I've released a WP7 app which you can now use to directly look at the problematic zoom behavior described above. It's interesting that the first reviewer calls out this zoom behavior as the one area he/she would like to see improved.
http://windowsphone.com/s?appid=aa9075b7-fb3d-4476-a5b8-a4e8035d788c

