06.28.07
Posted in Job Tracker at 12:13 am by Cal
Here are this week’s figures from Dice for progress in job postings for C# and WPF:
WPF All of Dice: 87
Silicon Valley: 3
Blend All of Dice: 2
Silicon Valley: 0
Silverlight All of Dice: 18
Silicon Valley: 1
C# All of Dice: 7541
Silicon Valley: 239
Sadly, I missed a week due to overload with the end of the spring term and three MSDN Webcasts.? However, I added a new feature to my Job Tracker:? Silverlight. Over the three months that I have been keeping these records, WPF jobs have risen by about 50% on Dice (57 - 87) and by 400% on Monster (25 - 104).? Over the same period, C# jobs on Dice have risen by 14% (6631 - 7541) overall but declined by 4% (250 - 239) in Silicon Valley.?
Permalink
06.24.07
Posted in Silverlight at 12:25 am by Cal
Silverlight is hot and gives every impression of getting hotter.? Check out the following blog article on its arrival on Linux.?
Permalink
06.23.07
Posted in Silverlight, WPF at 3:03 pm by Cal
I would just like to emphasize one aspect of Alan’s report on the Silicon Valley Remix07 event. About half way down the report are three photos which both of us agree are near the top of the important news coming out of this meeting.? The slides depicted in the photos show what Microsoft’s plans are for the future development of Silverlight.
? As everyone who has tried to work with Silverlight knows, one of the initial barriers to success is the limited support for WPF controls and other WPF features.? These slides show how ambitious are Microsoft’s plans to include a much wider collection of features in the upcoming Version 1.1 release of Silverlight expected for later this year.? Notice, for example, how most of the important basic controls are scheduled for inclusion in the next version.?
? Anyone interested in where Silverlight will be going over the next year would do well to study these slides carefully.?
Permalink
Posted in Silverlight, WPF at 2:46 pm by Cal
Reported by Alan Cobb
www.alancobb.com
I (Alan Cobb) and Cal Schrotenboer attended Microsoft’s ReMIX07 event in Mt. View, CA yesterday 2007-06-22. The talks I liked best were the keynote by Scott Guthrie (Microsoft General Manager of the development teams who build the CLR, WPF, Silverlight, ASP.NET and IIS, among others: http://weblogs.asp.net/scottgu) and the Silverlight technical drill-down by Tim Sneath (Microsoft WPF/Silverlight evangelist: http://blogs.msdn.com/tims/)
Scott Guthrie demoed a chess application which included one mode which pitted .NET against Javascript. Since .NET excutes much faster than Javascript to the great pleasure of the audience it always wins each chess match.
Tim Sneath gave a very convincing explanation of the importance of Silverlight.
What evidence is there that Silverlight is “hot”? The original MIX07 last month in Las Vegas focused on the introduction of the Silverlight 1.1 alpha with its support for C# and .NET running in the client browser. That event sold out its 3000 seats several weeks in advance. Because of that sell-out and the enthusiastic response of the attendees, Microsoft decided on the fly to schedule additional ReMIX07 events to capitalize on the buzz. This ReMIX07 in Mt. View was one of those “overflow” events.
Tim Sneath’s slides showing the latest planned feature list for Silverlight was a technical substance highlight.? His slides compare the features for Silverlight 1.0, 1.1 and the full desktop version of WPF.
Cal and I were elated when we had the chance to talk directly with Tim for an extended time in a small group after his presentation was done. On a personal level, I’m struck by how unpretentious and personally “likeable” both Tim and Scott seem.
Tim Sneath explains Silverlight to Cal
Permalink
06.17.07
Posted in WPF, WPF Animations, XBAP at 3:27 pm by Cal
www.alancobb.com
Alan is a friend of mine from Sacramento who is taking my Spring 2007 WPF class. I knew before Alan took this class that he was a talented developer but I had to raise my eyebrows when I noticed that he consistently scored 100% of all of the tests. I’ve been teaching for quite a while and I can assure you that that doesn’t happen very often.
I asked Alan if instead of the regular lab assignments he would mind working on a Greeting Card project which I could then incorporate into one of my MSDN webcasts (coming up on June 21st). The format which Alan chose was an XBAP application. He decided for the first project to create a baby announcement. After digging through my collection of 70,000 digital photos I selected a baby picture which I took last summer of the daughter of a couple of my friends from the Netherlands.
Alan’s Greeting Card illustrates quite a few WPF features including several different animations and audio. For a complete list of features illustrated, see the Documentation page.
Permalink
06.16.07
Posted in WPF at 9:20 pm by Cal
One of the main claimed benefits of WPF is “resolution independence”. Often this benefit is described in relatively vague terms leading people to believe that it means that the same WPF window will display on any monitor at the same size regardless of the resolution at which that monitor is set.
For example, one might imagine that if a user originally sets his monitor to a resolution of 1280 x 960 and later changes it to 640 x 480, a WPF window which was originally sized at 4″ x 4″ at the higher resolution should still display at that same size even after the monitor’s resolution has been changed. Unfortunately, a simple experiment will prove that this interpretation of “resolution independence” is not correct.
Another potential interpretation of this term is that a WPF window will display at the same size regardless of the monitor DPI setting. Right click Desktop, Properties, Settings, Advanced. On this property page you will see a combo box which is typically set to “Normal size(96 DPI)”.
Other options (at least under Windows XP) are “Large size (120 DPI)” and “Custom setting…”. One might reasonably hypothesize that since resolution independence evidently does not refer to the actual resolution at which the monitor is set (1200 x 960 vs. 640 x 480), that perhaps what is meant that a WPF window will display at the same size regardless of what DPI setting this property is set too. Again, unfortunately, another simple experiment will prove that this interpretation of “resolution independence” is equally invalid.
As it turns out, Microsoft was not really lying about the resolution independence of WPF. It is just that the explanation of what is meant by this term is a bit more complicated. The following experiments do indeed show that WPF is actually resolution independent.
We’ll do our verification by running a WPF test app on two systems with LCD displays that have different physical pixel sizes. The test app simply draws a 4 inch line whose length we will verify by putting a physical ruler beside it on the screen. The two test systems are as follows:
System 1: Desktop LCD monitor:
Screen width x height in pixels: 1600 x 1200
Screen width x height in inches: 17.0 x 12.75.
Therefore it has 1600 / 17.0 = 94 physical pixels per inch (physical DPI) horizontally and 1200 / 12.75 = 94 physical DPI vertically.
System 2: Laptop with LCD screen:
Screen width x height in pixels: 1400 x 1050
Screen width x height in inches: 12.0 x 9.0.
Therefore it has 1400 / 12.0 = 117 physical DPI horizontally and 1050 / 9.0 = 117 physical DPI vertically.
The key here is that the desktop monitor’s pixels are 25% larger than the laptop’s. (117 / 94 = 1.25)
Before doing the tests we need to review some terminology. While a classic Win32 app uses coordinates with units of “physical pixels”, a WPF app uses coordinates which are expressed in “device independent units” (DIUs we’ll call them here). One WPF DIU is defined as 1/96 of an inch. This definition of units allows WPF coordinates to be specified in inches rather than physical pixels. So a third possible interpretation of the term “resolution independence” might be that the same WPF application would display at the same size on two different monitors set to the same resoultion (1024 x 768 for example), regardless of the size of their physical pixels. Under this theory a dialog box that is 4 inches wide on System 1’s 94 physical DPI LCD should still be 4 inches wide on System 2’s denser 117 physical DPI LCD.
Unfortunately, the initial results of my experimentation seem to be at odds with this hypothesis. The following photos show that a line which is 384 DIUs wide actually displays at 4.08″ wide on my desktop monitor and at 3.28″ wide on my laptop monitor. Neither monitor achieves the desired result of displaying a 384 DIU long line at 384/96 = 4.00″.
The correct explanation, however, lies in a careful analysis of the interaction between two important display properties settings. The first is the screen resolution setting (eg. 1024 x 768) and the second is the “Advanced / DPI setting”. (See images above.) Both of them act as “scale factors” that let individual users force everything on their monitor to be displayed either bigger (for easier reading) or smaller (for more desktop real estate).
We can eliminate the first scale factor from our tests by requiring that the “screen resolution” be set to the “native resolution” of the system’s LCD display. Since System 1 has a physical resolution of 1600×1200 pixels we must assure that its screen resolution has been set to the same 1600 x 1200 pixels. In the case of System 2, the corresponding setting is 1400 x 1050.
The second scale factor, the “DPI setting”, is what we will vary in our tests. WPF doesn’t independently know what your monitor’s actual physical DPI value is. Instead WPF uses the current setting of this second scale factor the “DPI setting”. If the “DPI setting” does not match the true physical DPI, then WPF’s “resolution independence” will appear to break — although it really doesn’t.
Now let’s examine our full test results. We’ll begin with the 94 physical DPI desktop LCD.
For the first test we’ll use Windows default “DPI setting” of “Normal size (96 DPI)”, which is what most people use. The photo shows the line which we expect to be 4 inches actually measures 4.08 inches, which is 2% off. Why? Because our LCD only has a physical DPI of 94, but the “DPI setting” scale factor is telling WPF to act as if we have a 96 physical DPI display (also 2% off from the real 94 physical DPI).
Next let’s try tweaking the “DPI setting” to make everything larger and easier to read. For that we’ll change it to “Large size (120 DPI)”. Now the line we might have expected to be exactly 4 inches long actually measures 5.10 inches. Again the explanation is that we are “lying” to WPF about our monitor’s DPI. WPF acts as if it is running on a 120 DPI screen when in reality the physical DPI is actually only 94. The distortion ratios still match exactly: 120/94=1.28 and 5.10/4.00=1.28. Both are 28% off.
Finally we will try the rule suggested earlier. We’ll make a custom “DPI setting” of 94 DPI so that it matches the 94 physical DPI of this LCD. At last success! Now the photo of the ruler against the screen shows we are rendering a “4 inch” line that truly is exactly 4 inches long.
Having successfully explained all the test discrepancies for the 94 physical DPI desktop LCD, now let’s switch to the laptop LCD which has a physical DPI of 117 to see if the same experiment with this monitor will give us the same result.
For the first test we’ll again use Windows default “DPI setting” of “Normal size (96 DPI)”. This time the photo shows the line that we expect to be 4 inches actually measures only 3.28 inches, which is 18% smaller. Why? Because our LCD has a physical DPI of 117, but the “DPI setting” scale factor is telling WPF to act as if we have a 96 physical DPI display. Again the distortion ratios match exactly: 3.28/4.00=0.82 and 96/117=0.82. Both are 100-82=18% off.
For the final test we will again try the rule suggested earlier. We’ll make a custom “DPI setting” of 117 so that it matches the 117 physical DPI of the laptop’s LCD. Again the rule works! Now the photo shows our app is rendering a “4 inch” line that truly is 4 inches long.
In conclusion, we’ve seen that WPF really is resolution independent as long as Windows display properties scale factor settings are properly taken into account. What WPF Resolution Independence really means that two monitors set to their native resolution and which are accurately reporting their DPI settings to WPF will display the same WPF window at the exact same size. Under those conditions a monitor with 96 physical pixels per inch will display any WPF window at the same size as a monitor which has 192 physical pixels per inch. The only difference between the two is that the latter monitor will look much sharper than the former.
Permalink
Posted in Presentations at 6:10 pm by Cal
Last Tuesday I made a presentation for the Inland Empire .NET User’s Group in Riverside California.? This presentation was essentially an introduction to WPF which included building a simplified version of my Senegal XBAP application.? I also gave a brief demo of my Drink Mate Wedding Proof application.?
? The meeting was attended by about 20 people.? Our room was almost full so I guess that attendance must have been better than average.? Also, this group had a lot of questions — something which I enjoy a lot.? The group meets in the facilities of the Riverside Medical Clinic (shown in the photo above).?
To avoid the possibility of arriving late, my flight from the Bay Area arrived? before 1:30 in the afternoon.? After getting my? luggage and my rental car, I arrived in Riverside at around 3:00 (in plenty of time for my 6:30 meeting).? ? ? ? To use this extra time efficiently I went to the public library and practiced my presentation.?
? I would like to give special thanks to James Johnson for arranging this meeting and hosting it.? Everything ran very smoothly and I’m sure that he was principally responsible for that.?
? The next morning my wake up call was at 3:30 AM.? This allowed me to drive to the rental car company lot at LAX by 4:45 and to make my flight to Seattle by 6:15 AM.? Ouch, that two hours of sleep isn’t really enough.? ? Much as I dislike wasting my time sleeping, I undoubtedly need a lot more than two hours.
Permalink
Posted in Job Tracker at 1:19 am by Cal
Here are this week’s figures from Dice for progress in job postings for C# and WPF:
WPF All of Dice: 85
Silicon Valley: 3
Blend All of Dice: 2
Silicon Valley: 0
C# All of Dice: 7289
Silicon Valley: 225
WPF and Expression Blend both flat, C# down just slightly both in Silicon Valley and overall.
Permalink
06.11.07
Posted in Classes, MSDN Academic Alliance at 12:19 am by Cal
I have prepared a PDF flyer listing all of the .NET related summer classes which we will be offering at Foothill College this year. This flyer also describes the Foothill MSDN Academic Alliance program.
Please pass this flyer along to all of your co-workers and friends who might be interested in improving their understanding of .NET technologies.
Permalink
06.08.07
Posted in Job Tracker at 1:27 am by Cal
June 8, 2007
Here are this week’s figures from Dice for progress in job postings for C# and WPF:
WPF All of Dice: 84
Silicon Valley: 3
Blend All of Dice: 2
Silicon Valley: 0
C# All of Dice: 7344
Silicon Valley: 245
No appreciable change from a week ago. “WPF Rock Star” position still open — hurry with your resume before they snatch someone less qualified.
Permalink
« Previous entries
