This post was originally supposed to be about why blu is faster with WPF, hence the tweet in the image, but after some digging, an equally unusual happening supplanted my original purpose for this post. If you decide to download blu, feel free to follow me as well; blu is a fine application if you don’t mind the occasional random crashing.
When Vista was being developed, the ability to magnify WPF vector graphics was included as an accessibility feature: vectors scaled in the magnifier on a WPF app would be easier to see and read, thus making this feature highly beneficial for those with diminishing sight. However, down the road, the WPF guys decided to scratch this feature in SP1.
Now, before I start, it’s best to know what vector graphics are. Outside the usual jokes about vectors thrown around during the Longhorn days when Aero Diamond managed to be a very persistent rumor, not many people actually understand the benefits of vector graphics over raster images (or, for that matter, what a vector graphic even is).
- Raster images are built pixel-by-pixel stacked like brickwork to generate an image. Because of this, raster images aren’t any good once you start zooming in and seeing the individual pixels. Generally, raster images are great for photographs simply because there’s far too much detail to be captured through points and lines, which brings us to vectors.
- Vector graphics, on the other hand, are built using a series of points connected together by way of instructions for various types of lines. Along with fill, effect, and other instructions generally used to make things look pretty, that’s really all a vector graphic is. Because of this, vector graphics are great for web graphics and other computer-generated things which don’t require photographic precision (Corporate logos are a great example). Thanks to the fact that vector graphics are rendered upon request, they’re infinitely scalable; all you’re doing when scaling a vector graphic is scaling the math behind the scenes.
Here’s the thing: this feature was supposedly nixed from Vista SP1, but before I found out about this, I tried scaling blu in the magnifier. The text scaled just fine, while the rest of the app did not (though this second bit could just be due to how blu was designed). I tested this out in Windows 7 and found that vector scaling in the magnifier was also kept out of Windows 7, as you can see by the fact that the text in blu is not magnified in Windows 7’s magnifier.
Well, if you take a look at the leading image at the top of this post, you’ll clearly see that vector scaling works in Vista SP1 at least with text (the unmagnified app is to the left).
Anyone have any ideas? I should note that I am on Vista SP1, and I do have .net 3.5 installed.
Follow Bryant on Twitter! 
Huh, I thought this app was called *chirp…
Do you have .NET 3.5 SP1 on your PC? (it should be there, if all Windows Updates have been installed accordingly)…
I think, especially for the new zooming stuff in Win 7, (thank you MS for having a look at magnification in OS X – it was time!) “vector based” zooming for WPF applications could be really astounding and useful for a lot of usecases (like presentations, etc.)…
However they simply may not want the Windows UI look bad besides a vector based WPF application in zoomed mode.
Well, whether .net 3.5 SP1 is installed shouldn’t matter given the date of Greg Schechter’s post (3.5 SP1 was put out in mid November of last year). However, I don’t think it’s installed, so i’ll go ahead and see what happens when I install it.
Oh, I have overlooked the reference to vista sp1
My mistake… Will test it locally tomorrow…
And it should be back.
I see there have been some nice additions to WPF. The Effects framework in particular – I hated that the only effects in WPF were BitmapEffects, which made whatever you applied them to a raster. Even things like drop shadows, which are pretty easy to make yourself. It just got annoying when I had to dig through old code to isolate the vector drop shadow part and copy it over.
It should also be noted that vector graphics are smaller than raster graphics by a staggering amount, and they compress very well on top of that. That makes it better for things like Silverlight and web apps, since you don’t need to wait for a massive raster to download.
Microsoft should make better use of WPF. It doesn’t deserve the neglect it’s been having so far.
@Karl: The original post I planned regarding Blu actually discussed in great depth the advantages of vectors over rasters. The advantages mostly exist because vector graphics are just instruction sets for rendering images on the screen, compared to raster images actually being the images themselves being spat onto the screen.
WPF feels like it’s being smothered. The fact that out-of-process scaling was chopped kinda proves my point, but I’m not sure what to think since it’s still here and I can still see it.
@GRiNSER, an update for you: I installed .NET 3.5 SP1 and nothing has changed.
@Bryant, thank you that you tried it out since i had no time for it so far (currently modelling with Maya for my 3d classes assignment).
Maybe it has something to do with the graphics card/drivers?
My take on WPF as I followed it from early Alpha to its current state: In the beginning it was exciting, when it came out it was still great but too slow (BitmapEffects, etc.) and lacking of features (DataGrid anyone?).
Now it has gained both in performance and features but it is still not where it should be (making stunning apps is still not easy). Hopefully .NET 4 will fine-tune the few problematic areas and MS finally will use its framwork for building great flagship apps!
I dislike about MS development technology that they have so many ways for building apps but none of them allows you to build great ones easily. The technology behind (like SQL Server, Programming Languages like C#, etc.) is excellent but the UI technologies are either difficult to use (Win32) or not ready for primetime (WPF).
Creating beautiful UI for applications should be made easy for developers and designers! Simple things such as nice looking controls, animations and transitions should be common sense but even WPF does not do this well: Have you ever tried, for example to add animations to a ListView control? I don’t know it for the recent version, but adding animations for removing an item or adding an item is very difficult.
Another problem is the lack of guidelines for Windows applications. Well there are some Windows UI guidelines made available by Microsoft but they are insufficient. Additionally, MS doesn’t even conform to its own guidelines so why would an external developer do it?
In contrast, Apple stands to its own paradigms (not everywhere but much tighter than MS) and guidelines. Therefore its plattform has a more consistent User Experience. Microsoft has to tackle the problems in this area to finally become a leader instead of a follower in great (looking and easy functioning) applications.
Huh, this post got long – maybe I should start to blog? If I had time for it…
Looks nice, something that SHOULD be taken in.
@Grinser
You can bet that if Apple had spent so long developing a platform as massive as .Net 3.0, it wouldn’t have been neglected. It would be in all Apple’s devices and products. Thing like Cocoa and Core Animation show that – it started on OSX, was almost instantly adopted by developers, and made it across to the iPhone where it’s an important part of the interface (horizontally sliding pages in settings would be confusing without the animations). Microsoft is too large a company – they can set a team on a massive project like this without fixing it in stone in the plans of other products. .Net 3 was originally called WinFX (as in framework, not ‘effects’) – it was supposed to replace the old Win32 stuff with Avalon, the hellish storage system with WinFS, and whatever it was that Indigo replaced. It wasn’t just an add-in like Java – it was more like Cocoa – it was a fresh new API for the OS.
Interestingly, I ran across a blog post (http://blogs.msdn.com/ianm/archive/2006/04/19/578851.aspx) where a commenter asked why WinFX wasn’t called .Net 3.0, and the blogger replied that calling it .Net 3.0 “wouldn’t do it justice”. Once they renamed it .Net 3.0, they lowered their expectations for it and it just slipped in to a historical footnote. That said, the same blogger claims WinMo 6.5’s horrible honeycomb interface must have taken a “leap of faith of lateral thinking” to create, so it’s possible he’s insane.