Description

• See the math and visual science behind how Windows abstracts physical display density and viewing distance • Why this means you can work in effective pixel space across all devices • How Windows makes full use of the physical pixels for you • What has changed for Windows 10 and why • When you have to know about physical pixels and why: bitmap assets and layout grids • How assets are picked through MRT and how to use MRT to manage assets and asset packs • Guidance: best practices on which scale factors to support: tradeoffs between quality and footprint • How to port assets from other platforms to Windows apps • Why scaling and layout grid go hand-in-hand, and the benefits of sticking to the layout grid • When you have to know about physical pixels and why: some advanced application requirements and techniques • API support you need to write an app that knows about physical pixels Speaker: Steve Wright

Scaling algorithm will optimize font sizes for perceived size rather than physical size. It allows designers and developers to use same font size for different device sizes. For example, 24px font will look relatively the same on phone and desktop computer.

@Eugene:Thank you!But do you consider supporting vector assets in near future? Web apps are moving towards vector and that's extremely convenient when you do responsive apps. Could you give an idea what are the biggest issues with vector assets in native apps (Windows Universal/XAML)? Rendering performance?

1) Vector assets are incredibly compact compared with bitmap assets, even with good bitmap compression. Using color font glyphs, for example, we typically see compression of 100:1.

2) SVG is a standard with fairly ubiquitous support in HTML/CSS engines, but significantly less cross-platform support in the industry's various graphics APIs. Some of the things that are cool to do with SVG, like animation, would require the platform to support the SVG DOM model.

3) Font glyphs provide a vector graphics technology which is supported everywhere text is supported (that is to say, everywhere), but color support is limited today to Windows. If you are only developing for Windows, this is a great choice which is available today in UWPs, both HTML and XAML. Performance is not an issue since we've been working on text performance for many years. Animation is possible, but only by cycling glyphs.

4) Vector graphics are not a silver bullet for scaling purposes. I had some slides which didn't make the cut that discussed this. Content can appear blurry if the transformed geometry isn't "snapped' to target physical pixels, and compliant implementations are free to do or not do pixel-snapping (or to do it in different ways). And even with good pixel snapping, content with repetitive patterns can end up with visible aliasing effects at some scale factors with pixel-snapping. So authoring vector artwork which stands up well at different scale factors and on different rendering implementations can be a challenge. With color fonts, this takes the form of hinting the font, something which requires tooling and expertise to do well.

So this is an area we are keenly interested in, but our current support is limited to color fonts and we don't expect this to be a mainstream developer technology until there's better and simpler tooling.

Great overview and it answered all my questions when it comes to scaling for icons (and a then some). Really liked that you hit on the memory impact of assets for scaling down. It would be very helpful if that table made it into the documentation.

@TonyB: We have nothing new that we are ready to share right now beyond what we covered in BUILD 2013 and BUILD 2014 for Win32 apps (except of couse that we now support up to 400% scaling). However, if you look at the taskbar and the file explorer app in WIndows 10 desktop, you'll see that they are both scaling themselves crisply based on per-monitor scale factor, at least in the most visible "top tier" UI. We've learned things in the course of this work that we hope we can turn into developer guidance in the future.

I've been work with UWP for a long time, but scaling has always felt like a bit of black magic to me. This should have an equivalent document (there is something that does address some of this but leaves out a lot of important details). And it should be front and center for all uwp designers and devs. This is actually critical information.