Feeds:
Posts
Comments

Posts Tagged ‘Metro’

The other day I was looking at the Google Analytics data for my Windows 8 app and discovered that almost 5% of my users were running a resolution of 1371.42858886719 x 771.428588867188. Huh!?

The bad news is, this was due to a bug in the Google Analytics SDK for Windows 8 and Windows Phone — which I wrote! 🙂

The good news is, I have since fixed it, learned a lesson (that I should have already known), and can now share my findings with you.

The point of this post is to walk through the subject of detecting physical screen resolution from within your Windows 8 and Windows Phone apps. Although not terribly complicated, it is slightly more involved than you might expect. The cruxes are 1) there is no single API to query the size of the screen your app is running on and 2) you need to understand how a certain magical feature called scaling works.

First, what not to do:

You might be tempted to determine screen resolution via the following mechanisms…

For Windows Phone 8:

Size resolution = new Size(

    Application.Current.Host.Content.ActualWidth,

    Application.Current.Host.Content.ActualHeight);

For Windows 8:

Size resolution =

    new Size(Window.Current.Bounds.Width, Window.Current.Bounds.Height);

The problem with this code (there are actually 2 issues for Windows 8 but I’ll get to that next) is that it doesn’t account for scaling.

Scaling is an awesome feature built into the platform where the OS attempts to stretch everything on the screen so an app will display at an ideal and consistent DPI regardless of the physical screen size and resolution. It does this by fooling the app into thinking that it’s running at a lower resolution than it actually is, but internally scales everything up to the real resolution before showing it on the screen. Also important to know: assets will not lose quality when they have more pixels than the pre-scaled size (this will make sense after my example below).

An example of scaling:

Let’s take an example of a 10.6” 1080p monitor (note: this is one of the screen resolutions you can set the Windows 8 simulator to).

Because this resolution is fairly high but the physical screen size is fairly small, Windows will automatically enable scaling and fool your app into thinking it is running on a lower resolution monitor. To re-iterate, this is a good thing because it means you as a developer or designer don’t have to worry about your UI looking really tiny on this particular device. To your app, the dimensions of the app (as reported by the APIs above) will actually be 1371.42858886719 x 771.428588867188 and so fonts and icons and shapes, …etc in your app will conveniently layout nicely and end up appearing at a similar size and position as it would on a 10.6” 720p monitor. Scaling gives you this little gift for free without you as the developer writing special code to change font sizes, …etc depending on physical screen DPI.

Avoiding pixilation!

I won’t get too much into the weeds about pixilation or best practices but I feel obligated to discuss 2 important things:

1) If you build your UI using a vector language (Xaml & HTML are vector languages), Windows and Windows Phone will be able to scale your UI to get the most out of every pixel without pixilation. Your app doesn’t need to do anything extra; scaling will automatically occur when visual elements are rendered and every pixel will be used. Learn more about vector graphics if that doesn’t make sense.

2) Assets like images and videos will automatically scale to fit the final resolution, not the fake application resolution. This one might be a little counter-intuitive. Imagine the following Xaml to display a 300×300 image:

<Image Source="/img300.png" Stretch="Uniform" Width="214" Height="214"/>

Because we set the width and height on the image control explicitly, your first impression might be that the image will always be stretched (Stretch = Uniform after all) to 214×214. The correct answer is: it depends.

If Windows has determined not to scale (because your monitor and resolution are close enough to the ideal DPI), then yes, the image above will be shrunk down to 214×214 when displayed on the screen.

However, if Windows scaling is occurring (lets assume at 1.4x), the image will actually be displayed on the screen in it’s full 300×300 glory. (214 * 1.4 = ~300)

To prove it, here are 2 images I created in Photoshop from the same vector source. One is saved at 214×214 pixels and the second is saved at 300×300 pixels. Using the following Xaml:

<StackPanel Orientation="Horizontal" Background="White">

 <Image Source="///img214.png" Stretch="Uniform" Width="214" Height="214"/>

 <Image Source="///img300.png" Stretch="Uniform" Width="214" Height="214"/>

</StackPanel>

When scaling is turned off (1x scaling):

image

Notice, the images look identical. This is because Windows will shrink the 2nd image (300×300) down to 214×214 before displaying it on the screen just like the Xaml says to do.

When Windows is scaling at 1.4x:

image

If you look closely, you can see that the second image is crisper. This is because the 300×300 pixel image is actually being displayed on the screen at 300×300 pixels despite what our Xaml’s height and width say will happen. The first image is actually being stretched to 300×300 when it is rendered to the screen.

Back to detecting resolution. And the correct answer is…

Easy, simply get the scaling factor (accessible via an API) and multiply it by the dimensions we gathered earlier.

For Windows Phone 8:

var content = Application.Current.Host.Content;

double scale = (double)content.ScaleFactor / 100;

int h = (int)Math.Ceiling(content.ActualHeight * scale);

int w = (int)Math.Ceiling(content.ActualWidth * scale);

Size resolution = new Size(w, h);

For Windows 8:

var bounds = Window.Current.Bounds;

double w = bounds.Width;

double h = bounds.Height;

switch (DisplayProperties.ResolutionScale)

{

    case ResolutionScale.Scale140Percent:

        w = Math.Ceiling(w * 1.4);

        h = Math.Ceiling(h * 1.4);

        break;

    case ResolutionScale.Scale180Percent:

        w = Math.Ceiling(w * 1.8);

        h = Math.Ceiling(h * 1.8);

        break;

}

Size resolution = new Size(w, h);

Almost there, don’t forget about snapped mode and orientation.

…I warned earlier that there was a 2nd problem with the Windows 8 code at the top.

For the Windows Phone, you actually don’t have to do anything. There is no such thing as snapped mode on the phone and Application.Current.Host.Content.ActualHeight and .ActualWidth always return values as if the app is running in portrait mode (even when it’s landscape).

For Windows 8, you do need to account for both snapped mode and orientation.

To help with this, you can compensate based on the ApplicationViewState. For example, here is the code I use to calculate the actual screen size, even when in portrait mode or filled mode (filled mode is when another app is in snapped mode next to your app).

if (ApplicationView.Value == ApplicationViewState.FullScreenLandscape){

    resolution = new Size(w, h);

}

else if (ApplicationView.Value == ApplicationViewState.FullScreenPortrait)

{

    resolution = new Size(h, w);

}

else if (ApplicationView.Value == ApplicationViewState.Filled){

    resolution = new Size(w + 320.0 + 22.0, h); // add the width of snapped mode & divider grip

}

The only thing lacking here is detecting the screen size when the app is snapped mode. While this bothers the purist in me, I find that most users don’t start apps in snapped mode so as long as you get the resolution at the beginning of your app’s lifetime and remember it, 99.9% of the time you will be able to accurately determine the actual screen resolution.

Worthy of mention…

Apparently it is possible using DirectX and C++/CX to determine the actual screen size. I haven’t tried this for myself but there is a blog post on how to detect screen resolution from a C++ WinRT component here.

Additional resources

Scaling to different screens

Guidelines for scaling to screens (Windows Store apps)

Multi-resolution apps for Windows Phone 8

Advertisements

Read Full Post »

A few months ago I was speaking with a reporter and was asked which development model the industry was gravitating toward for Windows 8 apps. My impression was that Xaml + C# appeared to be strongest out of the gate but only time would tell if JavaScript+HTML would slowly close the gap.

So far, this hasn’t happened. C# (and VB) + Xaml development has held its ground as by far the most popular development model for Windows 8 Metro Store apps. In fact, preference is now over 3 to 1 over JavaScript + HTML.

Since early April, I’ve been taking random snapshots of the number of posts on the MSDN Windows 8 development forums and here are the results…

UPDATE for Oct 28: C#/VB gains even more ground…

image

image

Raw data:

Model 9-Apr 14-Jun 31-Jul 22-Aug 28-Oct
JavaScript 3645 5926 7831 8573
10631

C++ 2779 4494 5647 6263
7914

C#/VB 10030 16337 21921 24798
34562

What is the trend? If anything C# is gaining share…

imageimage

imageimage

I have numerous opinions about why this is the way it is, but I’ll leave this speculation for another day. Why do you think C# and Xaml are more popular for Windows 8 development? Or is counting forum post a poor way to measure?

Read Full Post »

In case you missed the news, Microsoft just hit a major milestone on its road to shipping Windows 8 with the public launch of the Release Preview version. With this new version comes new features and as expected: a number of trivial, yet importing changes that will affect app developers and their apps.

Meanwhile, here at Vertigo we’ve been toiling day (and sometimes night) to help developers and clients prepare for this update so they can hit the ground running and create some of the first apps to ship on the new platform.

One such effort that we were proud to release alongside the launch of Windows 8 Release Preview is the update to the Microsoft Media Platform Player Framework (an open source video player component for Windows 8 metro style apps).

win8_pf.jpg

While Windows 8 includes some essential and great components to help building top notch media apps (namely the MediaElement for Xaml developers and the Video tag for JavaScript/HTML developers), the purpose of these components is primarily aimed at providing the fundamentals and low level support for playing audio and video. We here at Vertigo Software know video and we know that there is still a mountain to climb before you can ship a great media app. In a joint effort with Microsoft, we’ve worked hard to fill this gap by building a media player framework to make it simple and straightforward to accomplish the vast majority of your media app needs in Windows 8.

The Microsoft Media Platform Player Framework ships with a JavaScript and Xaml version of the framework that offers out of the box features to build great video apps without the fuss and months of development required to build your own media player. Besides support for the Windows 8 Release Preview, our latest update also includes support for major features such as player DVR controls (scrubbing, FF, RW, play/pause, …etc), player styling and branding, closed captioning, and just released today: video advertising!

Video advertising is very different from traditional banner advertising – which is already included with the Microsoft Advertising SDK. Video advertising allows you to seamlessly connect to video ad servers and stitch together commercials, overlays, and companion ads with your own content.

Advertising is an extremely important monetization strategy for many media companies and an equally significant undertaking to build from scratch. With the latest version of the player framework, you can simply add the new advertising plugin, schedule when ads should play and point your app at a VAST standards compliant ad server to play ads with your content. Ad scheduling, downloading, playback, and tracking is all handled for you by the player framework using IAB recommended standards such as VAST and VPAID.

Download everything you need today to start (or finish) your media app for Windows 8:

Microsoft Media Platform Player Framework

Windows 8 Release Preview

Visual Studio 2012 RC

Smooth Streaming SDK

PlayReady DRM SDK

 

Enjoy!

Read Full Post »

Need to build an app that plays video? This week we released a new version of the MMP: Player Framework (formerly the Silverlight Media Framework) made for Windows 8 Metro style applications.

With guidance the Windows 8 and IIS teams, we (Microsoft Media Platform team & Vertigo Software) created an open source media player framework that you can use for both HTML-based and XAML-based Metro style applications.

image

Support for HTML and XAML

The player framework supports both HTML/JavaScript and XAML/C#/VB based Metro style applications. Technically, there are two different components (one for HTML and one for XAML based apps), but they share very similar APIs, feature sets, and in some cases even share the same source code. Under the hood, the XAML version is built on top of the MediaElement that ships with .NET and similarly, the HTML version is built on top of the HTML5 <video> tag.

Our primary goal was to ensure both flavors felt natural and familiar to both HTML and XAML developers. If you are an HTML/JavaScript developer, using the JavaScript version will be very similar to using the other JavaScript controls that ship with Windows 8 as well as those already familiar with the HTML5 <video> tag. If you are a XAML/managed code developer, you can expect the XAML version to adhere to the practices and patterns of .NET & Silverlight controls.

Extensibility

The framework: We refer to the player framework as a framework as opposed to a control or component because it is intended to be a mini-platform in it’s own right. While these details will be hidden to the majority of developers using it as is out of the box media player, the player framework is built on a plugin style architecture that enables the feature set to be expanded and evolve after the fact without touching the core code base. In fact, many of the features currently in the framework are implemented as plugins. For example: the main control bar that the user interacts with is technically a plugin that could be swapped in our out for a radically different implementation.

Styling: One of the most common requirements in building a media player is to be able to skin the UI to match your brand. By default, the player framework ships with a Metro style skin, but you can easily modify the look and feel of the player from CSS or XAML without having to build a custom player.

Open source: the player frameworks ships with full source code under the liberal Ms-Pl license. Crack it open and see how it ticks or make changes to suite your needs.

How similar is it to the existing HTML5 or Silverlight versions of the player framework?

You may already be familiar with the existing HTML5 for the web or Silverlight for the web/desktop and phone versions of the player framework. The Windows 8 version of the framework should feel familiar and is in fact based on much of the same code. However, you should not expect full compatibility. We wanted to make sure the player framework felt like it was made for Windows 8 Metro style apps and it’s respective development model (HTML vs. XAML). We also wanted to meld the two versions and their APIs when it made sense. Lastly, we used this opportunities to make architectural improvements that would better position the framework for a long and bright future.

Features

You’ll find that the player framework has an extensive API chocked full of many useful hooks and features. From 30,000 feet, here is a sampling of features you will find in v1 of the player framework.

  • VOD
  • Progressive video
  • Smooth streaming
  • Rich DVR (Play, pause, stop, fast forward, rewind, skip next & back, seek-able timeline, volume, slow motion, instant replay)
  • Full screen
  • Closed captions (plain text for Xaml and WebVTT for js)
  • Styling support
  • Buffering and error/retry visual states.
  • Poster image
  • Click-to-play UI to let the user choose to start watching.
  • All features already included with the MediaElement and <Video/>
  • Playlist
  • Chapters
  • Timeline markers
  • Support for localization
  • Compact UI for snapped view
  • Support for DRM (e.g. PlayReady)

What’s next?

The fun doesn’t stop here. We’re already hard at work on more features. Here are some prominent ones in the cards.

  • Adaptive streaming APIs
  • Advertising
  • Audio player
  • TTML closed captions
  • Audio track selection (multi-language audio)
  • Live video

Got feedback?

We’d love to hear your feedback and make sure the player framework offers the features and functionality you need in your apps. We encourage developers to check out the player framework on CodePlex and post feedback on the CodePlex forum.

Hope you enjoy!

Read Full Post »

In my earlier post I created a high level breakdown of the APIs shared by both Silverlight and WinRT…

image

Here I’m providing a complete reference of all 6,585 public types and 15,248 members included in Silverlight 5 and/or WinRT and where they overlap.

My hope is that this will serve as a reference to Silverlight developers trying to get up to speed with WinRT.

Click here to see the WinRT Genome Project results.

image

 

Note: Please let me know if you see an errors or have requests. I’ve only begun to comb over these results myself and will be looking for ways to improve it going forward. Enjoy!

Read Full Post »