SilverLite

Perf Debugging Tips: EnableRedrawRegions & a performance bug in VideoBrush

Was chatting with Andy Beaulieu at Remix Boston, and he was commenting that it seems that Silverlight only draws when needed -- it is true, we try to not waste your CPU cycles. For Perf debugging, a way to tell when you are causing a redraw is to turn on the control's EnableRedrawRegions property.

agControl.settings.EnableRedrawRegions = true;

With this feature on, when a section of the plugin causes a draw, that section will draw in a different color. This setting is not for those susceptible to seizures =P

Bug found: With this setting, I investigated a performance issue with VideoBrush. In our 1.0 Silverlight bits, VideoBrush always requests a redraw in the next frame. This is a bug. Unfortunately, if the control framerate is set to the default (60 fps), then any VideoBrush will be redrawn 60 times in a second. In actuality, VideoBrush should draw at the framerate that its media is getting refreshed (eg. 30fps, 15fps, or 0fps if paused), and should not take up so many CPU cycles. We have a fix for this bug in 1.1. If you are blocked by this bug, please let me know and I can pass the info along to our servicing team.

A workaround is to set the framerate on your Silverlight control to be the same as the framerate of your video. There are visual artifacts to this workaround, but it is slight

Sys.Silverlight.createObjectEx({

source: "xaml/Scene.xaml",

parentElement: document.getElementById("SilverlightControlHost"),

id: "SilverlightControl",

properties: {

width: "500",

height: "500",

background: "black",

framerate: "30"    //only as much as needed

}

Macintosh & Silverlight perf...

I met recently with two designers trying to figure out "what was Silverlight doing under the covers? did I accidentally turn on some feature?" 

My first thought is to reference my post on how to minimize CPU usage. We have to learn how to conserve not only energy but CPU cycles (yes, even if you don't see a difference on your dev box)

My second thought, as I stared at the designers' laptop: have you checked out Apple's Shark tool made for the Mac? Pretty quick and easy to learn -- you can navigate through the entire callstack of Silverlight.

For the Silverlight mac developers out there, check out Shark:

• Using Shark: http://developer.apple.com/tools/performance/optimizingwithsystemtrace.html
• Link to download "Computer Hardware Understanding Development" (CHUD) tools: http://developer.apple.com/tools/download/

My general usage:

1. Launch my silverlight application in a browser
2. Direct Shark towards the browser's process
3. Click on Start (it should have a 30sec timeout by default)

When you see the callstack, anything with agcore is from Silverlight. 

Why is it named agcore? From Wikipedia: "Ag from the Latin Argentum is the chemical symbol for silver "

Enjoy, tell me about your experiences. Any successes? Any questions about what is showing up in the trace?

See you at Remix Boston!

Weather has turned dreary in Seattle already, I'm headed to Boston for a bit of warmth and to see the leaves turn....but more importantly: I'm giving a talk at Remix Boston on Tuesday at 9am, introducing Silverlight as a developer and media platform. Send me a ping if you would like me to delve into a particular topic.

See you there, 
Seema

Silverlight: A few thoughts on minimizing CPU usage

1.       IsWindowless=false is faster

Do not turn on isWindowless unless your design requires overlay of other HTML content on top of Silverlight content.

2.       Opaque Background is faster

Do not set a transparent channel in the Silverlight HTML control background property. Setting the background to a transparent or semi-transparent value will add tremendous cost as each render call is forced through the blending pipeline, regardless if the transparency has any visual effect. (A background of 0, transparent, #11aabbcc, etc. will cause blending)

If you simply want to set the control’s background property to match that of the HTML, background:document.body.style.backgroundColor will suffice.

Note: I am referring to the background of the Silverlight HTML control. Setting an opacity on elements within your Silverlight app has relatively minimal cost.

Note: if you do decide to use transparency, please make sure to test the performance on Mac:Safari.

3.       Only offer the quality that is needed for your design.

-          Framerate: you can set the max framerate for the entire contents of the control in properties. Many websites run all animations and media at ~15fps, and most users do not notice.
Note: I set the value of the framerate property below.

-          Media: When encoding your media file, remember that the average media file on the web is roughly encoded at 320x230, with ~15fps.

4.       Test & Debug

-          Quality and performance vary on different machines, and even on different OS/browser configurations.

-          The below onLoadHandler shows how to display the framerate, for debugging purposes, in IE or Safari’s status bar. If your desired framerate is out of reach, you should set the framerate property lower so as not to peg the user’s CPU.

Sys.Silverlight.createObjectEx({

source: "xaml/Scene.xaml",

parentElement: document.getElementById("SilverlightControlHost"),

id: "SilverlightControl",

properties: {

width: "500",

height: "500",

background: "black", //NO ALPHA =)

version: "0.9",

framerate: “15”    //only as much as needed

},

events: { onLoad:onLoadHandler} });

 

function onLoadHandler() {

/* To see the framerate displayed in the browser status bar */

agControl = document.getElementById("SilverlightControl");

agControl.settings.EnableFrameRateCounter = true;

}

 

 

HW Acceleration of Layered Windows - Good news!

Good news! A QFE has been released to enable WPF HW acceleration on layered windows on XP:

http://support.microsoft.com/kb/937106/en-us

enjoy!

a vista simulator in WPF/E?

This is very sweet... click on the button on the left

http://www.vista.si/main.htm

(I don't know what the right button does...translations are welcome)

Feb CTP for WPF/E is here!

The most recent CTP for WPF/E on the Windows and Mac are now live. Check out the details on Mike's blog

http://blogs.msdn.com/mharsh/archive/2007/02/01/wpf-e-pad-and-others-updated-for-the-feb-ctp.aspx

Enjoy!
.seema.

A Chat with WPF experts and other news...

Our wonderful platform evangelist, Tim Sneath, has organized an event to talk to the WPF experts. I will unfortunately not be able to attend as I am celebrating my birthday with my family. =) 

Tim sends out the formal invitation:

Following on from a couple of requests, I'm delighted to announce that we'll be hosting our first ever live online technical chat with the WPF team on the MSDN site next Thursday, December 21st, at 12:30pm Pacific Time (that's 3:30pm ET, 8:30pm GMT, 9:30pm CET). We'll have a collection of the WPF team on hand to answer your technical questions, hear your feedback on what we should be doing in our next release, share great tips and tricks for using WPF, and just generally connecting with one another.

If you're interested, you can click on this ICS file to add the appointment to your calendar. And please feel free to RSVP in the comments section below so that we know to roll out the red carpet for you!

Hope to see you there!

...In other news, I have moved from the WPF team to the WPF/e team to learn more about cross-OS and web development. I will no longer be working on our MIL team.

Happy Holidays!
Seema

“Why do my bitmaps look blurry?” by Anthony Hodsdon & Miles Cohen

Guest Writers: Anthony & Miles are Developers on the WPF 2D Graphics team. Anthony specializes on our Geometry, Miles focuses on the Brushes codepath.

On some monitors, it seems that thin WPF lines are blurred across two pixels instead of one. Ick. How do I get sharply rendered lines?

WPF offers a way to get sharp lines and keep anti-aliasing, by auto-magically aligning the horizontal and vertical edges of a UIElement to land on the pixel grid when you set UIElement.SnapsToDevicePixels=true. The property inherits: set SnapsToDevicePixels on your topmost UIElement, and on the first child of every VisualBrush that you want sharp lines on.

When SnapsToDevicePixels=true, the layout system produces 2 horizontal guidelines and 2 vertical guidelines that coincide with the bounding box of any UIElement. These 'guidelines' are produced during the Measure/Arrange passes, and hint to MIL to place that boundary lines on the pixel edge.

SnapsToDevicePixels only affects horizontal and vertical lines. Setting this property will also help situations where you want abutting edges. Here are some pictures of the old ListBox style with and without SnapsToDevicePixels set:

Why should I care about the pixel grid? WPF graphics are anti-aliased and device-independent, which is a great story for high-resolution machines. However, if you have a black one-pixel line that lands in between two pixels on a low-resolution machine, we will color the two pixels 50% black and 50% white (also known as Grey).

Shall I just adjust my line offsets manually? Should I round my doubles to ints? No, this will make your application device-dependent. On a machine with 120-dpi, an app optimized for 96 dpi will have blurry lines.

How does it work? The WPF graphics layer, MIL, takes any specified guideline and ensures that that coordinate lands on a whole pixel. To do this, MIL might shift your lines up to .5 pixel in either direction. Any line affected by the horizontal guideline will be adjusted the same distance as the guideline. Thus, if you have a horizontal line with the same y-coordinate as the horizontal guideline, that line will be placed on the pixel grid. If you have a vertical line with the same x-coordinate as the vertical guideline, that line will be placed on the pixel grid.

Pixel snapping only affects horizontal and vertical lines that have a specified GuidelineSet.  SnapsToDevicePixels creates guidelines that coincide with the bounding box of your element -- for a Rectangle, having SnapsToDevicePixels generate those guidelines will ensure that the lines of the Rectangle land on the pixel grid.

A few things to remember:

This is a hinting mechanism, not sure-fire.

We still respect the anti-aliasing rules: if you specify a line that is thicker than a pixel, we will still spread that line across 2 pixels.

Layered windows...SW is sometimes faster than HW

Previously, I had posted that Avalon’s layered windows on XP will be rendered via the software pipeline. One can create a layered window by setting Window.AllowsTransparency="true". I’ve seen a few forum posts about performance issues, and the key takeaway point is that your mileage will vary depending on your video card.

In order to render layered windows via our hardware pipeline, we need to circumvent the fact that DX Present cannot handle a window with transparency. Instead of using DX present, we render via DX, grab the surface (via GetDC) and present with GDI. GDI is not hardware accelerated on the Vista WDDM video driver model. The above results in a chain of bitblits from video memory to system memory to video memory which creates a performance hit on many video cards. However, with a unified memory model (eg. Intel Lakeport 945g), the rendering of layered windows is faster in hardware than in software, as the bitblit goes from system memory to system memory.

To substantiate the performance hit that could arise from the aforementioned bitblit chain with a few numbers, I did a bit of testing on a card without a unified memory model (nvidia geforce 6800, WDDM video driver). My setup is a recent Vista build, Aero Glass theme, 2.5GHz P4, 1.5 GB RAM, single-monitor, single-video card.

Animating the translation
Scenario: Translating a single 50x50 rectangle around a 300x300 semi-transparent window
Observed: Framerate with hardware acceleration was at ~50 frames/sec. With software, ~ 60frames/sec.

Resizing, forcing an entire redraw
Scenario: With the mouse, resizing an empty 300x300 semi-transparent window with no window style to 300x600
Observed: Framerate was ~8 frames/sec when hardware accelerated. With software, ~60 frames/sec.

Frames with sufficiently complex rendering, particularly 3D, can pass the inflection point and will see a boon to having hardware accelerated layered windows. For layered windows with simple 2D content, our hardware codepath has typically a worse framerate than the software rendering codepath on the video cards without a unified memory model. The enabling of layered windows came late in the game for v1, and we’re looking at developing a more refined codepath for rendering layered windows in vNext, stay tuned.

Key takeaway: a semi-transparent window is a particularly complex feature for WPF's rendering system. Figure out early what type of hardware that you expect your app to run on, the performance that is acceptable for your users, and whether you want to use Window transparency.

After animating text, the text seems to pause for 1 second and then render more sharply than before. Why is that?

HW Acceleration of Layered Windows for RTM

To obtain GPU-accelerated rendering, Windows Presentation Foundation (WPF) normally renders and presents graphical content through the DirectX pipeline – including the composition of the scene geometry and presentation of the results.  

Since before Windows XP, Win32 has supported an alternative window presentation mechanism called “layered windows”.  Layered windows allow for top-level window transparency effects when composed with the desktop; on WPF, this feature is available by setting Window.AllowsTransparency="true".  For example, to get a dropshadow effect, WPF composes Menus and Popups as layered windows.

There are two aspects to rendering: composing the scene, and presenting the surface. The Windows Vista D3D 9.0 graphics API provides support for rendering to surfaces with an alpha channel, but does not directly support a mechanism to present that surface to the desktop and retain alpha information. On Windows Vista, WPF renders via hardware accelerated DX, acquires the surface via IDirect3DSurface9::GetDC, and presents to the screen via GDI.

DirectX 9.0C, the version of DX available on Windows XP, does not support IDirect3DSurface9::GetDC of a surface with an alpha channel. As such, support for hardware accelerated rendering when using Window.AllowsTransparency="true" will not be available on Windows XP from the RC1 and RTM releases of WPF.

Avalon Hardware Acceleration & Video Driver Compat

Hello. Seema Ramchandani here, PM of the Avalon 2d & 3D graphics team.

Many people have asked me about what is this celebrated feature called “Hardware Acceleration”. In this post, “hardware acceleration” refers to harnessing the GPU to render, leaving the CPU free for other calculations.

In Beta 2, Avalon attempts to hardware accelerate rendering on machines with video drivers newer than November 2004. Video drivers are implemented and made available by the video card manufacturers.

Our (my team’s and my) foremost goal is to ensure a stable and performant experience for as large portion of our users as possible. I’ve personally uncovered a few driver bugs in testing Avalon, and we want to make sure that the Avalon experience is not just performant but stable as well.  Looking at the machines in my parent’s home, I know that a large portion of users have the same drivers that shipped with the computer. Some of our users with 2 year old video cards may not get hardware acceleration, but they will get a stable experience.

In Avalon, we offload the rendering costs of many features to the video driver, but we first check the date of your video driver and what it can handle. We run a basic rating of the driver from 0-2 and store the value as RenderingCapability.Tier. What Avalon hardware accelerates does not change between XPDM and WDDM, it changes based on how we rate the actual video card: does the card support PixelShader 2.0, have X Mb of RAM, etc…

Check out the SDK article: Graphics Rendering Tiers[1]. Due to the memory virtualization features of WDDM, we do not have a VRAM requirement for WDDM drivers.

POR for Hardware Acceleration

For Beta 2, we accelerate the rendering of Avalon graphics on GPUs with:

-        WDDM drivers of all dates

-        XPDM drivers more recent than November 2004, regardless of the OS.

For RTM, we might change the Hardware acceleration story, and I will update this posting. Changes would be in response to analysis of crash reports from our Beta release.

What are XPDM and WDDM? Their differences?

-        XPDM: The Windows XP Display Driver Model.

-        WDDM: The Windows Vista Display Driver Model. [Microsoft.com]: WDDM is a significant evolution of the graphics driver infrastructure and will not be backwards compatible with XPDM drivers.                           

The WDDM video driver model is only available on Vista machines; XPDM video driver model is available for both Vista, XP, and Server 2003 machines.

The DirectX team and the video card manufacturers have worked hard to bring the WDDM model to fruition, which brings a more reliable and stable graphics environment. For example:

-        WDDM virtualizes their video memory: with this feature, your Avalon app is less likely to run out of video memory and fallback to software.

-        A larger portion of the WDDM driver code is run in user mode rather than kernel mode (as opposed to XPDM); if the driver crashes in the kernel, the machine blue screens.

3D Anti-Aliasing Story
Avalon only offers 3D-Antialiasing on WDDM drivers. WDDM offers a more stable model and video memory management, both of which are more desirable when using 3DAA.

Avalon 3DAA stresses video drivers in a way that, up to the release of the Windows Driver Kit, has not been heavily tested before. When it came between our XP users’ computers bluescreen or seeing aliased 3d, we chose aliased 3d. More to come on this topic later.

Why do we enforce a driver date check on XPDM drivers?

Standard DX GPU usage, before Avalon, was largely graphics-heavy games. In our testing, we uncovered bugs in older, XPDM drivers that were not seen by users. Most video driver bugs are never detected by the user, but interacting with some can result in rendering artifacts and/or crashing of the video driver.

A kernel level crash is bad news. We do not want users to blue screen.

In November 2004, Microsoft released a new version of the driver testing guidelines; the drivers written after this date offer better stability. Avalon will use the hardware acceleration pipeline for these drivers and will fall back to software rendering for drivers that do not meet this date.

-        Most machines released after November 2004 will have an acceptable driver out of the box

-        Users can also update their drivers by visiting the video card manufacturer’s website.

How do I find the date of my video card driver?

In a cmd shell, run “dxdiag” and go to the Display tab. Some Vista users will find that their video drivers have not been published yet. J

I think my video driver has a bug, how can I tell?

When you see rendering artifacts of an Avalon application, the bug might be in several layers of the Avalon, DirectX, video driver rendering chain. The first debugging step to take is to see if the bug repros without your video driver involved; try turning off Avalon hardware acceleration[2] and compare the rendering with and without hardware acceleration enabled.

If you see a difference, first visit your video card manufacturer’s website and downloading the latest video drivers for your card. If you still see a rendering difference between your Avalon app with and without hardware acceleration, please report the bug via Microsoft’s ladybug tool and attach:

-        Your driver information[3]

-        Description of expected and actual rendering

-        Simple application that repros the behavior (xaml-only is preferred)

-        Screenshots of both behaviors, if possible.

Links of Interest

-        Greg Schechter on WDDM & DWM
http://blogs.msdn.com/greg_schechter/archive/2006/04/02/566767.aspx

-        Windows Driver Kit
http://www.microsoft.com/whdc/DevTools/default.mspx

-        Submitting a bug report to Avalon
http://lab.msdn.microsoft.com/productfeedback/default.aspx

-        PCI Express FAQ off of Microsoft.com
http://www.microsoft.com/whdc/device/display/PCIe_graphics.mspx