I've been working on a WPF application that manipulates and renders a load of images, and came across an interesting fact that I felt compelled to share!
By default WPF renders at 96dpi (I know this can be changed in the OS, but lets not get into that now!), so when supplying an image with a differing dpi WPF will scale the image back to 96dpi while maintaining the original size!
The Problem
Example:
ImageA.png @ 72dpi W=720px H=720px (10in x 10in)
When displayed in WPF...
ImageA.png @ 96dpi = 960px x 960px (10in x 10in)
and
ImageB.png @ 300dpi W=600px H=600px (2in x 2in)
When displayed in WPF...
ImageB.png @ 96dpi = 192px x 192px (2in x 2in)
So in essence an image with a dpi less than 96 will appear larger than the original pixel resolution, therefore dpi’s greater than 96 will appear smaller!
This was causing me real problems as the images I consume are of varying DPI's, and I wanted to maintain the original pixel resolution on screen.
(Ok, so this is not really a problem as such as WPF is doing exactly what it should do, this only becomes a problem if you want to maintaining the original pixel resolution of the image)
The Solution
Well, kind of....
There is a property which can help you in the WPF world to overcome this issue, and this is the Stretch property of the Image.
Set width and height to the PixelWidth and PixelHeight of the image and set the Stretch property to Uniform, the images will now appear in WPF at exactly the same pixel resolution as the original images!
The reason I say "Well, kind of...." is - I'm still investigating whether WPF scaling the images to 96dpi, then me Stretch(ing) it back to the original pixel resolution is a lossless process or not (esp when dealing with high dpi images) I'll post back if and when i get an answer to this!
C,
- third letter in the English- and Romance-language alphabets. The symbol is derived from Latin C, a rounding of the Greek Γ, gamma.
sharp,
- able to cut: having an edge or point that is very acute and able to cut or puncture things.
- pointed: ending in a point or sharp angle.
- abrupt in changing direction: making a change in direction that forms an acute angle.
- quick-witted: quick-witted and intelligent or quick to notice and understand.
[Make of that what you will.... not much I guess.]
Sorry other CLR language centric .NET'ers - not wanting to explicitly exclude anyone, but C# is my .NET CLR language of choice, the language written for .NET (ok, I'll take the purist hat back off), and the language I'll use to demonstrate CLR coding scenarios throughout this Blog!
Nuff said!
Following on from my previous post where I spoke of a growing affection for the Silverlight 1.1 Platform, I want to quickly discuss a phrase I've heard a lot of over the past year or so "Application = Code + Markup". (referring to the appearance of XAML in the .NET GUI strategy space)
With the advent of CLR Languages running in the browser with Silverlight 1.1: are we starting to see a single CLR language across all tiers of your application?
To have a single language that spans every tier of an application and targets all platforms certainly has it's advantages, you can see the .NET vision forming as it begins to emerge from the mist!
- SQL2005 CLR Extensions for Data Tier (not mentioning LINQ as a unified query language/ORM)
- The established .NET Framework for the application services and communication channels (WCF, Web Service, or Remoting)
- and now... Silverlight 1.1 finally slots a CLR language into the most accessible UI delivery vehicle, the web browser!
From a development management and methodology standpoint, having a single mature development language utilised across all application tiers has got to provide a few benefits. A single set of coding standards, code analysis tools, unit testing tools/processes, and resulting maturing reusable code libraries. Perhaps reducing overall costs with fewer ranging (if perhaps more skilled) disciplines and reduced development time. And when this delivery provides a highly usable interface to the business, is this not a compelling argument when considering building a development capability.
Will this situation ever truly arise, I've learned never to say never (it usually comes back to bite you) and am hopeful that this new development in the Microsoft Technology Stack will lead us somewhere down this route. We cannot forget about Markup's major role in all of this, the apparent provider of the new "high fidelity" User Experience, as XAML seems to be the current Markup buzz word, so are we are starting to learn "Application = Code + Markup"...? I certainly am!
My main experience in the field of Microsoft's next generation GUI offerings has been from a WPF perspective, the more powerful, better performing, and comprehensive of the two brothers. I've also worked previously with Silverlight 1.0 and like the intention, but the lack of internal event handling means you end up with a stack of JScript to provide the interaction logic. I wouldn't go as far as lambasting JScript, it's just that replacing with C# in 1.1 means you end up with a much tighter and coherent package.
Despite this overwhelming power advantage of WPF, I see Silverlight 1.1 as the beginnings of a very exciting platform in my opinion, "a rich web technology for the .net generation"
At this early stage in it's development it's difficult to criticise what Silverlight 1.1 is offering by way of public release (it is after all currently only in Alpha).
The Current Frailties
You would perhaps consider...
- Where's that TextBox, Combo.... the input controls you require are not there.
- No Layout controls like DockPanel or StackPanel, just me and my Canvas.
- No reusable resources dictionaries
- Ok, no "big-bro" WPF style data binding framework - this is probably the biggest loss from the elder sibling, I agree!!
- Yes, you can currently do a lot more in Flash.
- And I've also heard of a couple of problems with it running on different platform!
But most of these reasons are exactly why I currently grow fond of it! As I begin to realise the full power and flexibility (and limitations) of WPF, and keep an eye on the strategy/actions the Product Team is taking - I can image how good it could be from a .NET developer perspective if this younger, weaker brother, gets anywhere near WPF capability. I also genuinely believe that with even only a few of the above mentioned features added on release this will be a nice start to a what will become an increasingly powerful platform (and ultimately a real contender to the space currently occupied by the likes of Flash and Flex)!
It's better by (simplistic) design??
In my many years of hands on software development I've met a lot of really clever people, writing "clever code". Unfortunately in many cases the code is only "clever" in a truly geeky/techie way, but from a readability/maintainability and management viewpoint maybe it's not too hot, perhaps it's even a bit on the convoluted side? Before I digress too far, and getting back to the point in hand, I like the look of Silverlight 1.1 because it is basic, and provides an obvious and simple (yet still quite powerful) framework. To a certain extent due to the language support (and therefore XAML definitions) being limited and the runtime not managing a binding framework, it provides a slick environment to implement the application behaviours exactly as you like them without any major management overhead.
In my opinion the cleverest design or implementation are generally the simplest and most succinct. As I've experienced in the past, sometimes developing large applications on expansive frameworks can provide developers with enough rope to hang themselves with. Maybe this is where "little-bro" Silverlight's lightweight framework approach might have a positive side-effect.
The Underdog
There is something to be said for the underdog (maybe it's a Scottish thing). Silverlight will probably always be in the shade when competing with "big-bro" WPF. The older brother currently has the key to direct GPU hardware access (pushing graphics processing off the CPU) and only has to run on a windows platform - easy job! But poor Silverlight will always have to run on all platforms - and with that scenario do you run into (what I call) the LCD factor when developing a truly multi platform application, will the Lowest Common Denominator factor always prevail. Perhaps they could enhance the capability on each platform/browser independently, but if the 3D render runs amazingly on a particular browser on a Windows box, will it look as good on a flavour or Linux... a Mac... etc?? Do we have to cut 3D from our app due to this LCD factor - only time will tell....
But it's ability to run on Multiple platforms will ultimately in my opinion be the factor that brings Silverlight mainstream, and leaves WPF behind in the "Windows Only" domain!
Well... it's a good few weeks in now, and as the nights are drawing colder the pace at iPrinciples is certainly heating up!! I've been working on some very interesting stuff over the past few weeks, particularly around the WPF and Silverlight space. These technologies have really excited me over the last year and I’m waiting in anticipation to see what's around the corner! I'll hopefully get the chance to share some of these experiences with you in this blog, giving an insight into what iPrinciples are doing, and perhaps even show you how were doing it!!
Before I go on, I should introduce myself; I’m Keith Walker.... "with a thirst for knowledge, and a love of all things 'code'!!"
I've contracted over the last 10 years, worked mainly in the Government, Publishing, New Media and Transport industry sectors. Although I have to say, starting out in (professional) life at a small software house for 5 years was the best introduction to software development I could have hoped for - these are the best places to get your hands really dirty in all aspects of the software development lifecycle! (I would highly recommend this environment to anyone really wanting to learn their trade)
My last role before joining iPrinciples was 3 years with London Underground. I was in the privileged position of having a relatively free role, tasked with driving the transformation of the development department from a traditional waterfall viewpoint with VB Client Server / Classic ASP to using an Agile approach utilising the .NET platform. This was a really challenging role; providing mentoring and guidance on tools, OO design principles and patterns, and practical implementation of the .NET Framework with up to 70 developers; system architecture and design sessions/reviews; evaluating and procuring new tools/components/platform; helping define development process and methodology..... (Honestly the list goes on... but I’m getting as bored as you now!). Great role, huge responsibility, wide exposure to many new technologies, and fascinating challenges within a fantastic problem domain!!!
During this time I advocated the drive towards a goal of a Service Orientated Architecture, firstly ensuring each developed application conform to a common architectural pattern with a primary constituent being a .NET web service exposing parts (if not all) of the application service tier. We latterly moved to a WCF approach, with one of the teams implementing a really nice WCF "WS-Eventing" based communication library set - full pub-sub over WCF, pretty sweet (perhaps some more on that later)!
This SOA drive was partly justified when we were evaluating a new rich web client GUI strategy late 2006. Our current Adobe SVG offerings were reaching the limits of the technology - we needed to do something, and quick! So, down the full evaluation path we go: Flex, Flash, have another go at stretching SVG again, or WPF. At this point we made contact with Microsoft to discuss their new technology and it's application into our environment. The end result of these conversation was a 3 week (15 day) Proof of Concept at Microsoft Technology Centre in Reading with 4 strong technologists (Stuart Harris - London Underground, Daniel Richardson - Edenbrook, Dave Brown - Microsoft, and myself), to take our existing SVG Front-ended Train Tracking application and prove it would work on WPF (almost a year ago to the day at time of this posting).
I was initially sceptical about what we could do in the time; "learn a new technology, implement this new technology with currently poor tool support, port all the track, signal and station level information from SVG into XAML, and set up a micro environment to mimic the heterogeneous back end data sources internally available at the Underground!"
But how wrong could I have been - we achieved all and more than I though possible in the timeframe. A topological and geographical high level view, a low level Track schematic view, and a 3d models of the underground - with animated train and signals movements from the (copies of) production web services. We not only managed to convert the application but we also added huge enhancements by drawing information from a further 5 internal web service. Now say you’re not as impressed as I was!!! It was a massive effort from all involved - but I think the results were well worth it. I ended up presenting the PoC demo at a live webcast of the Developers Launch of Windows Vista along with Peter Goss (The Boss!!!) who was responsible for managing the engagement and the delivering this PoC to the business (and yes, I’m the Scottish one getting excited about WPF and trains!!!)
If you watch the demo you might appreciate why I felt the SOA decision was a pay-off in this case, we were left with a rich user experience, drawing on content from several sources, giving the ability to overlay multiple data sources in context with real time events - and all developed in 15 days to a better than typical PoC standard! Fantastic job by all... (...if I say so myself) including WPF!!!
My last words on this subject have to credit iPrinciples very own Richard Godfrey for his contribution to this PoC, in his past life at Microsoft, for helping us to get there and enabling us to achieve what we did.
Anyway, enough about the past (and massaging ego's) - it's all about the future from now on! I know it's been a bit long for an intro, but I’ve hopefully set the scene of my background a little, putting my world into context.
I hope to provide some useful insight into my views on the many aspects of developing rich user experience applications on the Microsoft .NET platform in my blog from now on (well that’s the intention). Now that I’m just about out of breath, it’s time to sign off. I hope you tune in on occasion and contribute your thoughts! Cheers!
k.